Skip to content

Instantly share code, notes, and snippets.

@RobertAKARobin
Last active April 7, 2026 03:56
Show Gist options
  • Select an option

  • Save RobertAKARobin/a1cba47d62c009a378121398cc5477ea to your computer and use it in GitHub Desktop.

Select an option

Save RobertAKARobin/a1cba47d62c009a378121398cc5477ea to your computer and use it in GitHub Desktop.
Python Is Not A Great Programming Language

Python is not a great programming language.

It's great for beginners. Then it turns into a mess.

What's good

  • A huge ecosystem of good third-party libraries.
  • Named arguments.
  • Multiple inheritance.

What should be good

  • It's easy to learn and read. However, it's only easy to learn and read at the start. Once you get past "Hello world" Python can get really ugly and counterintuitive.
  • The Pythonic philosophy that "There should be one -- and preferably only one -- obvious way to do it." As someone who loves working within rules and rigid frameworks, I love this philosophy! As someone who writes Python, I really wish Python actually stuck to this philosophy. See below.

What's "meh"

  • Forced indentation. Some love it because it enforces consistency and a degree of readability. Some hate it because they think it enforces the wrong consistency. To each their own.
  • Dynamic typing. There are lots of dynamically-typed languages and lots of statically-typed languages. Which kind of typing is better isn't a Python debate, it's a general programming debate.

What's bad

  • 400 ways (more or less) to interpolate strings. This prints "Hello Robin!" 3 times:

    user = {'name': "Robin"}
    print(f"Hello {user['name']}!")
    print("Hello {name}!".format(**user))
    print("Hello %(name)s!" % user)
    

    If there was a unique and obvious use-case for each of these then that would be one thing, but there's not.

  • 69 top-level functions that you have to just memorize. GvR's explanation sounds nice, but in reality it makes things confusing.

  • map doesn't return a list, even though the whole point of a mapping function is to create one list from another. Instead it returns a map object, which is pretty much useless since it's missing append, reverse, etc. So, you always have to wrap it in list(), or use a list comprehension, which, speaking of...

  • List comprehensions are held up as an excellent recent-ish addition to Python. People say they're readable. That's true for simple examples (e.g. [x**2 for x in range(10)]) but horribly untrue for slightly more complex examples (e.g. [[row[i] for row in matrix] for i in range(4)]). I chalk this up to...

  • Weird ordering in ternary/one-line expressions. Most languages follow a consistent order where first you declare conditions, then you do stuff based the on those conditions:

    if user.isSignedIn then user.greet else error
    
    for user in signedInUsers do user.greet
    

    Python does this in the opposite order:

    user.greet if user.isSignedIn else error
    
    [user.greet for user in signedInUsers]
    

    This is fine for simple examples. It's bad for more complex logic because you have to first find the middle of the expression before you can really understand what you're reading.

  • Syntax for tuples. If you write a single-item tuple (tuple,) but forget the trailing comma, it's no longer a tuple but an expression. This is a really easy mistake to make. Considering the only difference between tuples and lists is mutability, it would make much more sense to use the same syntax [syntax] as lists, which does not require a trailing comma, and add a freeze or immutable method. Speaking of...

  • There's no way to make dicts or complex objects immutable.

  • Regular expressions require a lot of boilerplate:

    re.compile(r"regex", re.I | re.M)
    

    Compared to JavaScript or Ruby:

    /regex/ig
    
  • The goofy string literal syntaxes: f'', u'', b'', r''.

  • The many "magic" __double-underscore__ attributes that you just have to memorize.

  • You can't reliably catch all errors and their messages in one statement. Instead you have to use something like sys.exc_info()[0]. You shouldn't have a catch-all in production of course, but in development it's very useful, so this unintuitive extra step is annoying.

  • Dev environments. Setting up an environment is a problem in any langauge, but other languages have solved the problem better than Python. For example, while npm has its warts, it is widely accepted that a fresh environment should be set up with npm i && npm run [script]. Meanwhile each Python project seems to require a unique mish-mash of pip and pipenv and venv and other shell commands.

What's bad about the culture

Most programmers will acknowledge criticisms of their favorite language. Instead, Pythonists will say, "You just don't understand Python."

Most programmers will say a piece of code is bad if it's inefficient or hard to read. Pythonists will say a piece of code is bad if "it isn't Pythonic enough." This is about as helpful as someone saying your taste in music is bad because "it isn't cultured enough."

Pythonists have a bit of a superiority complex.

@doniaalani-alt
Copy link
Copy Markdown

Are you dumb? like list:itemnumber is cool and I also thought about making a Python compiler and when I finish I'll upload it on GitHub @RobertAKARobin and I don't know why nobody understands

try:
    # code here
except SyntaxError:
    # whatever you want if SyntaxError occurs

@codyskidmore
Copy link
Copy Markdown

In my view, Python absolutely has its own elegance especially when it leans into procedural and functional paradigms. The examples people shared highlight this beautifully: when Python is used as a clean, expressive scripting language, it shines.

Where the language starts to break down is in its approach to object‑oriented programming. Python’s OOP model often feels like it was bolted on after the fact rather than designed as a first‑class paradigm. The result is a set of syntactical quirks and structural compromises that make core OOP concepts such as inheritance, encapsulation, and interface‑driven design feel inconsistent or incomplete.

For small utilities or lightweight applications, these limitations are easy to overlook. But in large enterprise data systems, where clarity, maintainability, and strong architectural boundaries are essential, Python’s OOP model becomes a liability. The language’s loose encapsulation, dynamic typing, and reliance on conventions over enforceable structure can introduce ambiguity where enterprise systems need rigor. When you’re building platforms that must scale, integrate cleanly, and be maintained by large teams over long lifecycles, those gaps matter.

Python is a powerful tool, but its strengths lie in its procedural and functional roots not in serving as the backbone for complex, object‑oriented enterprise architectures. That’s why, for systems where OOP principles are critical to long‑term success, Python often feels like the wrong tool for my work.

@Jbla0712
Copy link
Copy Markdown

Jbla0712 commented Mar 26, 2026

It's a security disaster.
It's an interdependence disaster.
Its performance is passable.
Its backward compatibility is a disaster,
The worst of all! It should be illegal to sell software that runs on this garbage.

Example: I just started up and then reinstalled UVR 5 (EXE version), it crashes like crap.
I was playing around with PyTorch and CUDA yesterday. Everything related to CUDA and PyTorch is crap
So this piece of junk is dead and its installer can't even fix it

It's totally Python. It's unusable.
It's fun to build Open crap and share it on Git.
Special mention to Comfy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment