5 ms·

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

by davvid 11y ago

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.

Keyframe 11y ago
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).
ubernostrum 11y ago
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.
- srj 11y ago
  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.
  - ubernostrum 11y ago
    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.
    - 11y ago
Agathos 11y ago
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?
pwang 11y ago
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?

by davvid 11y ago

Keyframe 11y ago

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).

ubernostrum 11y ago

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.

srj 11y ago
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.
- ubernostrum 11y ago
  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.
  - 11y ago

Agathos 11y ago

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?

pwang 11y ago

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?