Python 2 is Stupid

Published: 2016-12-13

Tagged: python software thoughts rants

I don't really think that Python 2 is stupid, having used it for some years. It's the first programming language that I really came to love; heck, it's the foundation of my career.

Python is going through a rough patch at the moment what with the whole py2 vs py3 thing. You can feel something is up. Just visit the Python reddit. There was the over the top Python 3 bashing post by Zed Shaw and the excellent rebuttal by Eevee. When stuff like this happens, I usually just cheer from the stands because I think that the Python community is generally mature and knowledgeable enough to come out of this bloodied but unbowed.

The dam burst when I read Why I'm Making Python 2.8. I have a huge amount of respect for the skill and amount of work required to pull something like this off, but I'm dumbfounded by the approach. This franken-interpreter runs "Python 2 code and C-extensions exactly as-is, while also allowing Python 2 programmers to use the most exciting new language features from Python 3." This sounds like a half-measure, like something made out of duct tape and raccoons, then sold as the final product as often happens in our industry.

If Python 3's features are so exciting, why not just use Python 3? The author touches on this: "And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive." Yes, Python 3 is a major version bump and includes breaking changes. Changing a py2 codebase into py3 involves a good deal of work, especially large legacy projects that include unmaintained dependencies. But does this really make it harder for users to be productive?

If it's about moving a codebase over to py3 and getting access to all those goodies, then it's an issue of cost and value. If using new features costs more than the value derived from them then there's really no point in switching over. But you can minimize the cost of the switch by:

• Mandating that every new project has to use Python 3.
• Translate a py2 codebase into py3 piece by piece - get a dashboard where you can direct traffic to each new or old piece manually and selectively.
• If the above is too large and too legacy-ish, start by moving parts of it to its own service: extract the functionality into a new project, spin it off as a microservice, use the network-facing API as a natural interface[1].

Python 2.8 might sound like a good cost minimizer here because it gives you all the new features while only expanding a minimum of resources on changing the interpreter, but I think this is a classic example of going for a short term win and losing the long game. Kinda like grabbing fast-food at the last minute instead of packing a healthy lunch before going to work. Here are some of the long-term costs of going with 2.8:

• There will always be lag between it and Python 2-end-of-life and Python 3 (bugfixes, features, etc.)
• Packages created for Python 2.8 will not be compatible with Python 2 or 3, basically creating a little walled off ecosystem of its own.
• It doesn't fix the reasons behind the phase we're going through now (ie. text vs bytes). Instead, it encourages folks to stick to what's broken.
• Does not have the support of the PSF. What if Python 2.8 goes under in a year or two? How are you going to migrate franken-python to Python 3?

However, it does have some benefits:

• Allows you to defer the decision to switch over your codebase to sometime in the future. We don't work in a vacuum, there may be political or financial reasons why you need a band-aid like this.
• It might get Python 2 people excited enough about Python 3 features to make the jump.
• Purely educational: it's great to see how to modify the Python 3 codebase, add features, work with tests, etc. I'm definitely putting this into my "source code to read" folder.

That said, please please please use Python 3. It's extremely pythonic (eg. asyncio is way more explicit than gevent) and hell, switching strings from bytes to text is enough to make it worth the effort. I was well into two years of using Python until I understood how strings work in Python 2 (decode vs encode. This presentation really helped me). Because of how complicated this is, most Python developers that I know simply try random things until something sticks. Python 3 makes this issue really explicit and easy to understand, which is important because most people don't work with bytes - they work with text. Unless you're doing networking or low level stuff, you'll never need to touch bytes and having Python automatically treat strings as unicode text solves 95% of your day to day problems.

Notes

1: Just to get it out there: I'm not a microservice fanatic, I just think it's a useful tool when used consciously.