Skip to content

Instantly share code, notes, and snippets.

@RobertAKARobin

RobertAKARobin/python.md

Last active May 10, 2026 07:48
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save RobertAKARobin/a1cba47d62c009a378121398cc5477ea to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save RobertAKARobin/a1cba47d62c009a378121398cc5477ea to your computer and use it in GitHub Desktop.
Download ZIP
Python Is Not A Great Programming Language
Raw
python.md

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.

@cynthia2006
Copy link
Copy Markdown

cynthia2006 commented May 10, 2026

@Benzor94 f-strings are simple for basic usecase, but beyond that? It's a whole mini-language with too many quirks to remember. Most users, including myself, forget beyond just basic string substitution. Better to be verbose than esoteric. At this date Python has printf-style formatting, string.Template, format(), str.format(), f-strings, and t-strings for string interpolation. What did Python's zen say again? Ah, "There should be one-- and preferably only one --obvious way to do it". Sure buddy, it's all obvious which one to use, innit?

The third way (C-style) is pretty much a relic of olden times and should be considered mostly obsolete

logging still uses that very style of formatting. Even within the stdlib they couldn't arrive at a consensus. What consistency can you expect from a language like that?

You have stuff like max(), min(), pow(), any(), all() that are just general tools. Would it be better if these were in e.g. math and some other modules? You really don't need to know all that if you just start out with the language, and for most other languages these tools are shuffled around into various namespaces.

And, that's better. max(), min(), any(), all() should be iterator methods that yield another iterator. One of the disappointing bits of Python is the lack of method chaining for iterators. What could have been this:

[2,8,4,1,1,6,2,0,5,6]
  .map(x => x*x)
  .filter(x => x%2 == 0)
  .max()

is forced to be this nonsense:

max(filter(lambda x: x%2 == 0, map(lambda x: x*x, [2,8,4,1,1,6,2,0,5,6])))

And, yes, it would make more sense for pow to be in the math module; because it's a mathematical operation.

These weird functions that "perhaps should be methods" are behaviours implemented as dunder methods

Python's a duck-typed language, mind you. The excuse of “but it’s a protocol” isn’t justified. The protocol just could have been defined differently; e.g. if an object supports advertising it’s length it could do so using the .length property or .length() or .len() method. And, it would work because Python’s a duck-typed language.

... they are a form of operator overloading

I'm sure it's called function overloading, because those aren't operators—neither technically nor practically.

The consistency here is that each of these are implemented by dunder methods and they are all very general properties that lot's of stuff can have. The dictionary's my_dict.keys() method is a method instead of a keys(my_dict) function call is because this method is a particular property of a dictionary, it does not implement any special behaviour in regards to the language.

There are custom types that mimic dict, but aren’t dict. But to retain compatibility, you use duck-typing there. You’ve sabotaged your own argument here.

The parenthetical notation for chaining is fugly and in my opinion whatever comprehensions pretty much obsolete map and filter (but probably not reduce, ironically), but the return type is hardly the issue.

Not really, sometimes you just don’t want to collect into a container. And, I’d argue that method-chaining is far more readable than any comprehension. Regarding my previous example, here’s a comprehension-based version.

max(x*x for x in [2,8,4,1,1,6,2,0,5,6] if x*x % 2 == 0)
# or perhaps,
max(y for y in map(lambda x: x*x, [2,8,4,1,1,6,2,0,5,6]) if y % 2 == 0)

Can you call this readable? Because I just can’t; it’s like trying to apply makeup on an ugly beast. And, besides a filterMap operation, comprehensions aren’t all that powerful to begin with, as you yourself have stated; it’s conciseness is deceptive—good for simple cases, but horrible for anything more than that.

And speaking of verbosity, it’s good being verbose, than being a edgelord who speaks in oneliners.

@cynthia2006
Copy link
Copy Markdown

cynthia2006 commented May 10, 2026 •
edited
Loading

@RobertAKARobin Good rant! There are several weak arguments, but overall okay.

The language is overhyped for sure, and criticised for good reasons. I used to be die-hard Python fan when I was young, but I was disillusioned later, realising how nonsensical it had been in its design (if not more than JavaScript). These points apply as well.

  • Design inconsistenties within the standard library itself, and documentation far from systematic compared to JavaDoc or Doxygen.
  • No method chaining for iterators, only parenthetic chaining; it's very ugly, and most people steer clear from that.
  • Asynchronous programming is certainly hard to get started; it’s semantics are certainly not trivial. The presence of three different types Task, Future, and coroutines is certainly more complicated than JavaScript’s simple Promise (pun intended). And, every synchronous API requires an asynchronous flavour to fit into the paradigm.
  • Lambda functions are limited to a single line. Let’s be real—naming things is hard, and it's better to have anonymous functions than name them something irrelevant.
  • It's slow. The default and most popular implementation—CPython—doesn’t include a JIT, and PyPy isn’t as popular or on-par the development cadence.
  • There's no proper support for modern web features like HTTP/3 and QUIC in the major libraries, not request, not httpx, not even aiohttp. And the library authors/maintainers are reluctnant, and aiohttp has even taken a retrogressive stance—a return to HTTP/1.0.

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