What I Hate About Python

During an interview a while back, I was asked to name some things I hate about Python. For some reason, I choked and couldn’t think of a good answer (I kind of wanted to blame the interview process, but that’s a rant for another time).

Maybe I’ve just been programming in Python for too long, and that’s why I couldn’t think of something (or maybe I’m just a massive Python fanboy). On the other hand, I’ve been programming in JavaScript (which I generally like) for about as long, and I can think of at least a few things right off the top of my head (mostly related to weak typing).

I did a search to see what other people don’t like about Python to get some inspiration, but I didn’t come across anything I truly hate.

Things That Don’t Bother Me

Significant whitespace. I love it.

Explicit self. I guess it would be “convenient” if I didn’t have to add self to every method signature, but I really don’t spend much time on that, and it takes about 1ns to type (in fact, my IDE fills it in for me). There are technical and stylistic considerations here, but the upshot for me is that it just doesn’t matter, and I actually like that all instance attribute access requires the self. prefix.

“Crippled” lambda. There are rare occasions where I want to define more complex anonymous functions, but there’s no loss of expressiveness from having to use a “regular” named function instead. Maybe multi-line anonymous functions that allow statements would lead to different/better ways of thinking about programs, but I’m not particularly convinced of that. (Aside: one thing I do hate relating to this is the conflation of lambdas and closures–normal functions are closures in the same way that lambdas are.)

Packaging. I don’t know why, but I’ve never had any problems with setuptools. There are some issues with the installation of eggs when using easy_install, but I think pip fixes them. I am glad that setuptools is now being actively developed again and the distribute fork is no longer necessary.

Performance, GIL, etc. I’ve used Python for some pretty serious data crunching (hello, multiprocessing) as well as for Web stuff. There are cases where something else might have been faster, but Python has almost never been too slow (caveat: for my use cases). Of course, Python isn’t suitable for some things, but for most of the things I need to do, it’s plenty fast enough.

len(), et al. I don’t have anything to say about this other than it’s a complete non-issue for me. Commentary about how this means Python isn’t purely object-oriented makes me a little cranky.

Things That Bug Me a Little Bit

The way super works in Python 2 is kind of annoying (being required to pass the class and self in the super() call). This is fixed in Python 3, where you can just say super().method() in the common case.

Unicode vs bytes in Python 2. This is also fixed in Python 3 (some people have argued that it’s not, but I haven’t run into any issues with it yet (maybe it’s because I’m working on a Python 3 only project?)).

The implicit namespace package support added in Python 3.3 causes some trouble for my IDE (PyCharm), but I’m assuming this is a temporary problem. I also had some trouble using nose and py.test with namespace packages. Again, I assume (hope) this is only temporary.

Things That Bother Me a Little More

The Python 2/3 gap is a bit troublesome. Sometimes I think the perception that there’s a problem may be more of a problem, but I don’t maintain any major open source projects, so I’m not qualified to say much about this. Personally, I’ve really been enjoying Python 3, and I do think it offers some worthwhile advantages over Python 2.

Conclusion

There isn’t one. I left some things out intentionally (various quirks). I probably forgot some things too.

Post navigation

12 thoughts on “What I Hate About Python”

I use Python for system scripting and small projects. Overall, I quite like it. But what realy bothers me (and I do not know why it is not more widly mentioned) is missing syntax to mark end of block.

From time to time you need to refactor your code a bit more and moving various code blocks, adding if, try, … statements can completely break your code and you need to check it line by line, not to mention no IDE (using Emacs here) can guess what indentation is right. I really hate that.

I almost wrote something about how I like the lack of an explicit block delimiter. There’s no clutter of braces or end end end. I like Ruby, but all those ends really annoy me (I actually prefer {}). Plus, I think because of the lack of an explicit delimiter, you will generally be able to view more meaningful lines of Python code on your screen.

I think short blocks is the key to mitigating the refactoring problem. That and, to a lesser extent, the judicious use of blank lines so you can easily yank blocks.

As a dynamic language I think it is almost perfect.
But what really bothers me is that multi word function and methods names do not have a consistent syntax regarding word separation.
I always have to test or lookup if it’s “starts_with” or “startswith”, “symmetric_difference” or “symmetricdifference” etc.

Also I would have preferred if Python used camel case instead of underscores.

GIL – My use case is firing off long-running queries to Oracle. Using threads didn’t get me any performance boosts but using processes did. I sometimes question the point of the threading module (and I’ve never read anything where someone said “use threads, not processes!”).

2/3 Split – I agree with you about the 2/3 split. It worries me. Even if it’s only perception, which I think it is to a large extent, I feel like it’s slowly starting to split the Python community.

.exe – It drives me nuts that it’s very difficult to get a .py file to a .exe file (my deployment and development is strictly windows). The only one that I’ve managed to get to work is pyinstaller and it can be sketchy at times.

My perception that windows is a second-class citizen when it comes to python. Unfortunately a large portion of the business world that I code for is strictly windows and nothing but windows. That being said, I’d be curious to know whether Mac and *nix users also feel like second-class citizens and if so, it might point to a problem area with python (and programming in general).

Lastly, I’ve been doing some coding in Clojure lately and there’s something about Clojure that just feels more elegant. Can’t put my finger on why unfortunately. Whatever that “elegant” feeling is, I now miss it in Python.

GIL should not be held while oracle queries are running; if you are seeing is the oracle adapter you are using is buggy. The oracle server runs the queries and while waiting for the result there is no reason for python to hold the GIL. I use mssql a lot, and Pyodbc fixed this in 2008. the GIL is most definitely not supposed to be held for I/O tasks. Oracle has an article on python concurrency, try googling oracle python GIL.

I’m one of those interviewers who asks about “how do you think X sucks”. The reason is to tease out how experienced someone actually is with X. It quickly catches out those folk who are wildly exaggerating on their resume. Like all interview questions it isn’t a perfect indicator, but is a useful signal. Developers should be critical of their tools, and expect more :-)

I also ask about favourite editor. I don’t actually care what the answer is, but I do care that the candidate spends time looking for ways to improve their productivity every now and then.

The one thing that sticks out for me with Python (and many other languages) is how complicated it can be to get a simple 1 page website configured and working compared to something like PHP. I haven’t written any PHP for about 20 months or so at this point, but every time I need something simple, it seems like it’s just a lot harder to get it setup in Python.

I’ve been using python for data analysis nearly 10 years and I STILL HATE IT!

Reasons why:

1. Every programmer’s notion of the “pythonic” is different which means that they will crytpify even the very simplest of operations in syntax that is impossible to decipher and changes from python version to version. This means that is is tedious and time-consuming to read anyone else’s code.

2. I still spend 90% of my time trying to work out what is a list, tuple or np object and changing it to something else that will work with my subroutines. It is the epitome of stupid that a tuple object can’t be changed once written!

3. Python programmers tend to be arrogant young men who care more about their egos than reliable, robust code.