Cannon: Where are we in the Python 3 transition?

Possible? Probably. Easy? No. Python's interpreter is implemented with all kinds of global state (guarded by the infamous GIL) that shouldn't really be there in any better-designed engine. Look at Lua where every state-manipulating function takes a lua_State* parameter to manipulate rather than having some nebulous set of implicit parameters (import table, ). If Python had done the same thing, then the functions could just look at whether they have a Python2 or Python3 state and voilà, you're half way there. But instead, they valued the ability to continue using the same (well, similar) C API.

Remember why you wrote the code in Python rather than, say, C or Java in the first place: it was because, being a higher-level language, it would make you more productive and the code becomes easier to maintain. That doesn’t mean you don’t have to maintain the code at all.

For most companies, it isn't either, it is something like cattle...you want to make sure you aren't spending more on grain and water than the resulting beef will be worth.

In many situations, programs providing small marginal utility don't justify this level of care.

With container tech like Docker, its easier than ever to hide ugly dependencies away. Most people faced down with deteriorating dependencies will deal with it once in a Dockerfile and run out the clock.

Old code needs enough maintenance work to keep it up-to-date with changing requirements and such already! Needing to fix major portions of it because the language it's written in keeps changing randomly is just more pointless and annoying work. Even in open source projects.

People don't generally rewrite their C code every time a new version of the C standards come out. Fortunately, they don't have to, because the C standards guys are generally very good at maintaining backwards compatibility. C89 code still works fine with a C11 compiler. Aside from finally dropping gets() (which has been considered a bug for ages), I can't think of a single breaking change since the K&R->ANSI transition 25 years ago.

C++ has been much more unstable, but it looks like things may finally settling down. The only big thing I've seen recently that may _require_ source-code changes to old code is the replacement of auto_ptr with unique_ptr. Both are supported in C++11/14, but the former is supposed to be removed in C++17 (or so I've heard).

Other languages may lack the stability of good old C, but I can't really think of another _established_ language that's gone for wholesale random breakage of existing code the way Python did.

Most of the actual interesting development is concentrated in library code, and Py2 is very much alive and kicking there.

Oh, and don't forget that the second major Python implementation (PyPy) still barely supports Py3.

Except for the ones who have moved on to Go, Swift and even Java so they can be part of the modern era

Python3 is worthless in the modern era for anything but the most trivial scripting tasks. It brings nothing to the table and is hopelessly lagging, by decades, the capabilities of its peers

What's left of it, if you're representative of how it treats its own. I thought pythons weren't venomous snakes.

> In this sense, the Python “community” has clearly moved to Python 3.x.

You know, I'm simply one data point, but my employer maintains a rather sizable codebase (many hundreds of thousands of lines of Python 2.x) with lots of new code being produced and no clear path to migrating to Python 3.x in the near future; we are also a "tech" company, so this probably means we ahead of a lot of other users of Python. Even a lot of the high performance greenfield work I have been doing is yet again limited to 2.x because PyPy's support for 3.x is limited at best. I can't speak for the community at large, but to say that no "significant community" is interested in 2.x at the current time, is perhaps an overstatement.