Does anyone know what the main reason is for not updating from python 2? I'm genuinely curious as I don't really know any modules that won't work under Python 3 and I can't really come up with any other blocking changes that would make upgrading that hard.
I did the work for a reasonably sized project recently - a few hundred thousand LOC. It was long, boring, risky work. Let me rattle off some of the tasks.
Audit all strings coming in and going out for encoding issues. Update all dependencies to their python 3 equivalent. Replace dependencies that hadn’t been updated (typically older django dependencies). Use python-future to bulk update incompatibilities. Changes to metaclasses were annoying. Force all uses of pickle to use protocol version 2. I documented some more during the migration on Twitter https://twitter.com/jarshwah/status/1209381850822496256?s=21
We began getting the code base into a compatible position about 1.5 years earlier. A final push of 3-4 weeks of work got it over the line, with many bug fixes after the deployment.
Other older larger systems will have similar problems at a larger scale.
This isn’t a condemnation by the way. Python 3 is better. The only reason we held out so long was because of the business justification. Once we couldn’t wait any longer it got prioritised.
Many internal tools for one, platforms, etc. Hard to tell.
One industry example is https://vfxplatform.com/ - they just (this year) moved to Python3, but with some delays, from the site:
The move to Python 3 was delayed from CY2019 to CY2020 due to:
No supported combination of Qt 5.6, Python 3 and PySide 2 so Qt first needed to be upgraded.
Upgrade of both Qt and Python in the same year was too large a commitment for software vendors and large studios.
Python 3 in CY2020 is a firm commitment, it will be a required upgrade as Python 2 will no longer be supported beyond 2020. Software vendors are strongly encouraged to provide a tech preview release in 2019 to help studios with testing during their Python migration efforts.
The active development of Python 2.7 stopped in 2015, that was the time to start migrating. Seems like this application would never updated if 2 wasn't EOL.
There are still Classic Visual BASIC programs out there that haven't been ported to VB.Net or C# yet because of how huge they are and how hard it is to code that they cannot afford to hire developers to do it for them. The same is true of many old languages like COBOL.
I heard that some places still using Turbo Pascal for DOS and have to stick with 32 bit machines because 64 bit can't run 16 bit DOS code.
Yes, and you similarly can continue using python 2.7.18 for next 10 years, no one expects Microsoft to continue releasing new versions of the classic VB. A lot of python users have weird expectations.
Lot’s of code is simply unmaintained. The guy that wrote it is gone, it’s still running fine so nobody is touching it. Businesses don’t want to take the risk and spend the money to upgrade it. Maybe you don’t realize the insane amount of code that is in this state!!
If you depend on an unmaintained codebase where the original developers are no longer available, then that's a substantial business risk by itself.
Too many software development projects are treated as one-off events where people commission them and assume they will work forever without updates. Software requires maintenance, and people who commission software development projects without planning on how they are going to be maintained in the future are taking on risk. Any risk involved in updating that abandoned code in future is a consequence of that decision.
If that's the case then 2.7.18 will continue working and probably it is a bad idea to port it. A lot of work for minimum gain.
But if you actively changing the code, the maintenance will get more and more expensive. With packages dropping python 2 support if you discover a bug in one of your dependencies and fix is in package that no longer work on python 2 you'll need to backport the fix (and maintain your fork) or migrate your code.
This is in part due to a lack of foresight, but you can run into all sorts of weird issues that you'd never think of, like this one: we have a feature in our REST API that can return lists of items as CSV instead of JSON (yes, I know, it sounds weird). It requires no effort from our backend services; the api proxy takes care of it. Unfortunately, something changed with dict enumeration order between python 2 and 3, and so when we first tried to upgrade, the CSV files being spit out had a new column ordering, which of course would have broken customer code that relied on it.
The string-handling changes, while necessary, are also a bear to deal with. Since python is dynamically typed, you need to work to find all the places where you need to add a ".decode()" or ".encode()". If you don't have excellent test coverage already, you're going to miss some, and it'll be a game of whack-a-mole until you get them all... assuming you have actually gotten them all.
> something changed with dict enumeration order between python 2 and 3
Dicts were by definition unordered until Python 3.7 [0], so you were relying on undefined behaviour. If you need an ordered dictionary and support Python 3.6 or below, you should use OrderedDict [1].
> something changed with dict enumeration order between python 2 and 3
Enumeration order in dict keys was never guaranteed (until 2019), even on 2. So basically that code relied on undocumented cpython behaviour that was strongly advised against, i.e. it was broken already. 3 simply made the brokenness more visible.
I imagine the reason for not upgrading from Python 2 is the same reason you don't upgrade your car just because there's a new model out. (Or maybe you're the type who does, but I guess you can hopefully understand why others don't do that.)
I think the biggest issue seems to be that you need to migrate the whole thing at once. If it could be done incrementally it would be easier.
Although there are ways, you can still incrementally adapt code base to work on both pythons. Also pylint with py3k option, mypy can help. There's also six packages, but many people seem to had good luck with futurize.
There's also something that I tried a while ago and it surprisingly worked (although it might not work that well on larger codebase?), basically you can use Cython (not to be confused with CPython) to compile Python 2 code and then include it in python 3, this would enable migration file by file.
Your existing code work perfectly for now. Management failed to understand while they need to budget a team to upgrade when the project doesn't bring anything new to the table.
Our migration to Python 3 occurred with a new generation of the product. No new development is happening on the Python 2 product, and customers are being migrated off. The vendor who runs our old product (GAE) has promised ongoing Python 2 support, so there’s literally no reason to spend the time or money to migrate it, no matter how long it takes for the last customer to get off the old product.
In my work, it's software that offers a Python 2 module for scripting. I tried the naïve "upgrade" of copying the module into my Python 3 module library, but no dice. The software checked the version of Python, saw it wasn't 2.7.10 (yeah), and raised an error.
Because there's nothing to update to. Everyone who was working Python circa 2.7.0 has switched to working on a new, different language which they insist on misleadingly calling "Python 3" rather than come up with a new name like the Perl -> Raku folks did.
I think you are trolling, but in case you aren't; can you elaborate what is so different in Python 3? Granted, it is not a drop-in replacement but it is 99.9% the same thing.
