Python Is Not A Great Programming Language

python.md

Python is not a great programming language.

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

• What's good
• What should be good
• What's "meh"
• What's bad
• What's bad about the culture

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.

Python is just a worse Perl. And you cannot even retcon use strict into it.

How much worse? I can't say (full disclosure: I like Perl - for some tasks. If code has been written in reasonable ways. With all warnings and strict, i.e. "must declare variable" and related gobbledygook, switched on. And files kept small and everything properly organized into modules.)

Plus the forced indent syntax makes it so that you cannot write one-liners in Stack Overflow comments. Or Coursera exercises. Hah! 😞

But at least it's well documented. That's something that is indeed very important.

Many people say it's somehow uniquely "readable". But "readability" (for reasons of maintainability, or so it is said) should be a concern after "do you have proper static typing". Any-typed mutable stuff rather negates the effort and good intentions.

Plus the forced indentation seems to generate bad feature interactions with the rest of the language design. As in, you want to add something to the language but your indentation requirements block you from adding clean syntax; now what?. And I just found out that it interferes with experimentation, i.e. the "change-and-modify, comment-uncomment loop" that seems to be a necessary ingredient of getting something to work in Python (or, if one is learning, any other language really, try Clojure...)

Python for scripting the odd task, sure. It's much better than bash. But as someone on the Internet (rightly) said, it's very ill-advised, for economic or reliability issues, to try to build large software systems in Python.

And then can anyone rationally explain this:

my_list = ['foo', 'bar', 'baz']

def f():
    my_list = ['qux', 'quux'] # my_list is local to f()!
    my_list[0] = 'ggg'

f()

assert my_list[0] == 'foo'
assert my_list[1] == 'bar'
assert my_list[2] == 'baz'

def g():
    my_list[0] = 'texx' # this accesses the global my_list!

g()

assert my_list[0] == 'texx'
assert my_list[1] == 'bar'
assert my_list[2] == 'baz'

# But the interpreter / (bytecode compiler?) does not like this
# 
# def h():
#     my_list[0] = 'aloha'  # "cannot access local variable 'my_list'"
#     my_list = ['qux', 'quux']
#
# h()

def h():
    global my_list # now we can modify the global list
    my_list[0] = 'aloha'
    my_list = ['qux', 'quux']

h()

assert my_list[0] == 'qux'
assert my_list[1] == 'quux'

I just had to get this off my chest. Enough of this, I have an exercise in NumPy to do 😓 . And then it's over to Dart.

@KDean-Dolphin

Prolog (1980s-grade psychedelics),

Hah! No, Prolog is absolute genius once you understand how it even works (i had to reset my assumptions).

If there were some serious investment in Logic Programming instead of everyone throwing money at trying to reinvent a square wheel with the whole JavaScript ecosystem (a practical joke, shurely?) one might see some progress in computer science. There are a lot of excellent ideas out there.

Meanwhile, I guess there is Mercury (underappreciated too, needs a proper IDE)

@dtonhofer

Prolog (1980s-grade psychedelics),

Hah! No, Prolog is absolute genius once you understand how it even works (i had to reset my assumptions).

I’m happy to be wrong. I’ll give it another look, with the benefit of a few decades’ experience.

If there were some serious investment in Logic Programming instead of everyone throwing money at trying to reinvent a square wheel with the whole JavaScript ecosystem (a practical joke, shurely?) one might see some progress in computer science. There are a lot of excellent ideas out there.

I’m with you on JavaScript; it suffers from the many of the same issues as Python, but the language appears to be better managed, and there are some things in TypeScript that I really like. The build system is horrible, though.

Meanwhile, I guess there is Mercury (underappreciated too, needs a proper IDE)

I’ll take a look.

Added a bullet for setting up dev environments.

What have you tried with C++ when creating a UI? What didn't work? How can C++ development be any slower than using a shitty language that forces you to stare at a screen to make sure you indent properly? I'm looking at GTK, C++, Eclipse, Cmake. I'll never in my life touch Python, it sucks ass that bad. I'm mostly looking to create something that takes minimal space and works as fast as possible so even my old phones can run it. I want to be able to point my old phone at the printer and use it's camera and broadcast it via Wifi so I can view it on other computers and phones while being able to also control the printer.

For C++ GUIs, I have written a wxWidgets GUI for graphically designing power system survivability simulations. It's been a while, but wxWidgets is like Microsoft Foundation Classes, but cross platform. It uses lots of preprocessing macros! And more recently I've used Qt to design a plugin for MITK. I made a mesh editor plugin for fast 3D segmentation annotation for blob-like organs in medical images.

C++ GUI development is slower mostly because it involves having to compile every attempt. Every change you make requires compiling to test! And that's very slow for large projects. When you have a compilation error, you have to compile again after fixing the error! You also have to spend the time to setup the build system to pull in all the dependencies (include paths/library paths) to even build the thing in the first place! GUI toolkits like Qt are massive with hundreds of include files and dozens of libraries... you need to use something like CMake that can navigate the numerous includes/libraries of a GUI toolkit like Qt. On top of CMake, knowledge of library dependencies in Qt really helps!

For the end users, you have to do something like ship the Qt libraries and make sure those users have the proper dependencies or redistributables installed. Versions of dependencies is also an important consideration as different versions can break ABI! That's when you get dreaded symbol errors in Linux. Or you'll have to use something like Dependency Walker to figure out which symbols are missing on Windows.

Now in Python... you just import some Qt module and can instantly start making windows, buttons, text boxes, combo boxes, etc.... I had a colleague make a fancy network topology editor with PyQt in just a matter of hours! This time frame would be nearly impossible in C++! The key here is that you don't need build systems or compiling to make changes and test GUI changes or functionality. It just works out of the box with scripting languages like Python!

What do you get out of C++? Your program is probably going to run faster and it's likely more correct owing to all the compile-time type checks! What do you get out of Python, or other scripting languages? You'll be able to try things faster and with no project bootstrapping overhead.

Seriously?

More frequently than I wish. Python can break backward compatibility even if you "freeze" the packages. One outstanding case: PyYAML-5.4.1 for python 2. Yes, Python 2 is deprecated, but some project I know is still using it. It shouldn't be that hard to use the same versions used originally and it should run smoothly.

Another one: The advanced build systems like CMake/Qmake and the more recent ones for Qt/C++ are simply awesome. They allow you to do all sorts of things. The project I am working on right now uses a bunch of vagrant machines to run simple python programs. Not only that, but it needs a lot of scripts python/bash to setup the environment. It is simply extremely hard to setup the development environment. With CMake you can write elegant and simple "bootstrap" scripts that produces ready to run binaries, configuration included.

Want to use docker? Ok, just try on a new mac with Apple Silicon chip in it and this setup.

Next: Slow because you need to recompile. Well, you probably don't know it but, if you set it up properly you only need to compile the unit you're working on. With my current python setup it not only takes several minutes to run the startup script (which is generating configuration files and other crazy things pythonists think are cool), but you have to actually do it because you MUST restart uwsgi every time you change a character in the code.

@dtonhofer Python is just a worse Perl.

Amen. For grins, I spent 6 hours today writing a "simple" python script that parses a file, selects some matching lines using regex, categorizes them into two lists, combines them under certain conditions, then greps another list generated from another file for matches.

And then I wrote it in perl. In under 30 minutes.

Sure, I've been using perl since the pink camel book. But even if I subtract out the time spent doing Google searches for silly stuff like "how to create a class instance variable in python" (in a constructor, silly!) and setting many, many print statements to figure out why a two-nested-group regex match is returned as a list of tuples (never mind the fact that the list itself is mutable), and that python "re" doesn't support multiple group matches (but python "regex" does, but good luck Googling that, because you get all the regex hits for "re"), I still spent about 3 hours on it. It shouldn't be this difficult and arcane.

And call me old-school, but I'm pretty certain that data encapsulation is a necessary component of any language that claims to be object-oriented. Which makes python not an object-oriented language, despite what Pythonists want you to believe (I believe this quote sums up the iron-clad reason why python doesn't include encapsulation: "After all, we're all consenting adults here." )