Ted Dziuba

I’m a work-a-day Python programmer, and I don’t see a compelling reason to switch to Python 3. Sure, there are some neat bits and pieces that I would get in exchange, but a less broken Unicode model and some cleanups of syntax and the standard library are not nearly a big enough carrot to convince me to migrate existing, known-working code to what is effectively a new programming language. It’s also not enough of a carrot for me to learn the small, but still new, Python 3 syntax changes and constructs.

Learning Python 3’s nuances would not be difficult, but there is simply not enough payout to justify the investment.

There’s a great Q&A with one of the core Python developers about the migration process, and it’s very telling about how much “developer capital” the Python team thinks it has.

The Sunk Cost of a Language

If you buy something at a big department store, you’ll notice that their point-of-sale system looks like it came out of the eighties. That’s because it did. See, for something complicated like a point of sale system, the store made a significant investment early on to tie it together with inventory supply chains, sales staff commission structures, and national or regional pricing models. There’s a great deal of business logic ingrained in systems like that.

Technology has advanced pretty far since the time when the store originally installed these systems. You can buy systems now that make the checkout flow really fast - for example, signing for credit card transactions electronically and NFC payments by phone. If it takes you ten fewer seconds to serve a customer, then your volume can increase significantly, especially during busy shopping seasons.

Sure, there’s a quantifiable value associated with an upgrade to modern technology, but that value just doesn’t overtake the cost of the switch. I’m not talking about the direct cost of new hardware and software, that’s a simple capital expenditure, but the cost of the unknown is horrifying.

Taking this back to Python, you can consider the time and energy it would take you to learn Python 3’s libraries and idioms to be a capital expenditure. You pay it once, and it (supposedly) produces future value for you. However, I don’t think the future value it produces is worth the initial expense. What do you gain by migrating to Python 3? Some better Unicode handling, a cleaner standard library, and the promise of future updates and maintenance, since Python 2.x will effectively be discontinued.

Cool, I guess, but you’ve just told it to me, not sold it to me. If I’m going to migrate to Python 3, I need to believe that there’s some wonderful thing I’ll get at the end of the tunnel. I need to believe that something about this upgrade path will carry the language into the future.

I need to see the Global Interpreter Lock disappear.

The GIL As A Marketing Tool

There’s always a lot of technical squawking whenever the GIL comes up. This is not an “I Hate the GIL” post, that’s been done. The general understanding of the interpreter lock among Python programmers is that if you want to use threads and CPython, you’re gonna have a bad time. We could chew the rag about CPU bound vs. I/O bound for this whole coffee break, but at some point, the GIL will burn you if you’re using threads with CPython.

The canonical response from python-dev about this problem is “use multiprocessing”, which isn’t a real answer, it’s a “leave me alone” answer. Multiprocessing’s API mirrors the Threading API, sure, but there are always weird problems with it. Unexplained lockups, file descriptor issues, data sharing problems, all these things that make your average Python developer think that concurrency is really just an afterthought.

There are other Python implementations that don’t have a GIL, sure, but Jython isn’t as well supported as CPython, and IronPython runs on .NET (lol, no). And there’s always some stupidness getting your database to work in either of these, since the Python DB drivers are usually C modules that target CPython.

Anyhow, Python’s GIL is a turn-off for a lot of developers, including me. For me, I look down on the GIL because other programming languages don’t seem to struggle with this. In Java, you can make threads, and they behave the way you expect. Same for C++ and Perl. But in Python, there’s this issue niggling in the back of your mind.

If Python 3 could take away that issue, it would have a much stronger sell to the development community. Consider this conversation that I’ve fabricated to prove my point:

Developer: “Hey boss, I think we should use Python for our next project, because it’s a very productive and easy-to-maintain language.”

Boss: “I’ve seen Python used before, but isn’t there some problem with scalability? Something about threads? We should use a language that won’t have those issues.”

Developer: “Ah, yeah, the Global Interpreter Lock. That was a limitation of the legacy version of Python. The new version, Python 3, got rid of that, and it also has way better Unicode support, so our app will be easier to bring to international markets.”

Boss: “Alright, let’s give it a try. See if you can get a proof-of-concept together.”

The GIL is something that developers, rightly or wrongly, constantly bitch about. Now, Python 3’s backward incompatability is something new for developers to bitch about. From my perspective, Python is just getting worse over time. From my perspective, the core Python team is ignoring business realities.

From my perspective, Python 3 isn’t worth it, yet. I’m going to spend some time on professional development, and it looks like that time would better be spent learning a completely new programming language, because the risks are about the same, but the rewards are the speculative and unknown.

That’s the fun of it.