Comment by davvid | Hacker News Reader

Comment by davvid | Hacker News Reader

Parent Full thread

why has Python 3 adoption been so slow?

I can tell you about our situation.

We are an animation studio with decades of legacy Python 2 code. We sponser pycon and are one of the poster children for python.

We have absolutely no plans to switch to Python3.

Here are the various reasons:

- Performance is a big deal, and moving to a version of python that is slower is a no-go off the bat.

- Python3 has no compelling features that matter to us. The GIL was the one thing that should have been tackled in Python3.

- Since the GIL is here to stay, our long-term plan will likely involve removing more python from the pipeline rather than putting a huge effort into a python3 port.

- We have dependencies on 3rd-party applications (Houdini, Maya, Nuke) that do not support Python3

- We have no desire to port code "just because". Each production has the choice of either spending effort on Real Features that get pixels on the screen, or on porting code for No Observable Benefit. Real Features always win.

- Python3 has a Windows-centric "everything is unicode" view of the world that we do not care about. In our use case, the original behavior where "everything is a byte" is closer to UNIX. A lot of the motivation behind Python3 was to fix its Windows implementation. We are a Linux house, and we do not care about Windows.

- Armin's discussion about unicode in Python3 hits many of the points spot on.

Why has adoption been so slow? Simply because we have no desire to adopt the new version whatsoever. We'll be using Python2.7 for _at least_ the next 5 years, if not more.

It's far more likely that we'll adopt Lua as a scripting language before adopting Python3.

It's far more likely that we'll adopt Lua as a scripting language before adopting Python3.

And you're welcome to do that.

But "we want a language frozen in time forever so we never have to maintain code" -- which seems to be what you're aiming for -- is not a goal you can achieve short of developing your own in-house language and never letting it make contact with the public (since as soon as it goes public it will change).

Meanwhile, the libraries are moving on and sooner or later they'll either move to Python 3, or be replaced by equivalent libraries with active maintenance, and the distros are winding down their support for Python 2. Switching to something else, and probably just rolling an in-house language you can control forever, is likely your only option if this is your genuine technical position.

I think you're mischaracterizing the parent's post. Python 3 is slower, offers no compelling features, and uses a string storage model that he doesn't agree with. That criticism does not mean that he or she desires "the language frozen in time".

The real feature needed is to eliminate the GIL. That would be worth breaking compatibility over.

Python 3 is slower, offers no compelling features

Python 3.0 was slower than 2.7 due to several key bits being implemented in pure Python in 3.0. Since the 3.0 release (remember, Python's on 3.5 now) things that needed it have been rewritten in C, and as of Python 3.3 the speed difference is one. Also, on Python 3.3+ strings use anywhere from one-half to one-fourth the memory they used to.

As for "no compelling features", well...

* New, better-organized standard library modules for quite a few things including networking

* Extended iterable unpacking

* concurrent.futures

* Improved generators and coroutines with 'yield from'

* asyncio and async/await support in the language itself

* The matrix-multiplication operator supported at the language level (kinda important for all the math/science stacks using Python)

* Exception chaining and 'raise from'

* The simplified, Python-accessible rewritten import system

etc., etc., etc.

I'm 100% not picking on you but, I started programming in Python around 2004. When Py3k came out, I had exactly zero of these gripes. Not once did I ever say, "I wish urlsplit were in urllib.parse instead of urllib", or anywhere else. I had no problems with iterables, the async stuff (honestly with the GIL, why does any of that matter), exceptions or imports. I recognize that some users of Python did, library/framework devs, etc. But Py3k is a huge, incompatible, and confusing change for 90% of Python devs, and the benefits are things they didn't, and still don't care about. It was honestly just a bad decision.

for 90% of Python devs

Given how many people and projects suddenly said "yeah, actually, we want to be on Python 3 now" after seeing the new stuff in 3.4 and 3.5, I think you're overestimating the number of people who don't care about these features.

I take your point, but I have a few counterarguments:

1. Python 3.4 was released 7 years after 3.0. That's a very long time.

2. Assuming you're referring to the async features (none of the other stuff is really momentous), I can understand that for framework devs. It's really not a big deal for most users though, and because of the GIL, it's not as if they'll suddenly reap the benefits of parallelism. All it really means is nicer algorithm expressions and event loops.

3. There's no technical reason the new stuff couldn't have been added to Python 2. The roadblocks are manpower and politics.

4. Even if we stipulate async/await/asyncio are huge, busted Unicode support, 7 years of development, and breaking compatibility with everything is just a terrible tradeoff.

There's just no way this was a good idea, and Python devs could earn a lot of credibility back if they just said "oops". But there's no chance of that.

Short version sounds like: Python is a legacy language. We're not porting our legacy code and we're not starting new projects in Python.

I wonder:

1. Would this have changed if there was a Python 2.8 with some new features (but still a GIL) that ran most 2.7 code?

2. Is your experience representative, i.e. are teams just not starting new projects in any version of Python, even though so many did in the last decade?

Same industry, smaller scope here.

- We have dependencies on 3rd-party applications (Houdini, Maya, Nuke) that do not support Python3

This is our reason. It's a bit of a conundrum meets catch-22 situation. On one hand we would start using python3 if there would be a support for it, on the other hand no one wants to because of porting legacy code seems bothersome if everything works as it should. To be honest though, all of our python code is to augment those 3rd party applications. Everything we have that's not tied to those applications is C(99 more or less).

Thank you for your candid and insightful comments.

I am curious - if there was a GIL-removed version of Python 2, would you change your assessment that your "long-term plan will likely involve removing more python from the pipeline"? i.e. is the GIL the primary (or even sole) factor in that?

Reply on news.ycombinator.com