5 ms·

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

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.

TylerE 7y ago
Because giant codebase that would take effort++++ to do so for no perceived gain, with possible addition of new bugs.
- mywittyname 7y ago
  > effort++++ effort += 1 + 1 Ported to Python3 for you.
  - moonchild 7y ago
    Correction: effort = (effort := effort + 1) + 1
    - pansa2 7y ago
      Executable pseudocode!
  - nxpnsv 7y ago
    Clearly c got it wrong. The number of + should have been increment so e->e + 1 should be e+ e+->e+ +1 should be e++ ...
- imtringued 7y ago
  That's how we get decades old cobol codebases that nobody understands.
jefft255 7y ago
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!!
- 6gvONxR4sf7o 7y ago
  In some ways that's the whole point of code. You want to get to forget about it doing all these things without you.
  - takeda 7y ago
    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.
- JimDabell 7y ago
  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.
malkia 7y ago
Many internal tools for one, platforms, etc. Hard to tell. One industry example is https://vfxplatform.com/ 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.
- takeda 7y ago
  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.
  - orionblastar 7y ago
    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.
    - takeda 7y ago
      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.
vharuck 7y ago
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.
falcolas 7y ago
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.
wiredfool 7y ago
Personally, the main software I use at $DAY_JOB doesn't support python 3 yet. I'm not looking forward to the scramble when it does upgrade, as we're using a ton of community modules that may or may not be abandoned.
Animats 7y ago
Some of the older hosting services still support only Python 2, or some early crappy version of Python 3.
mehrdadn 7y ago
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.)
abathur 7y ago
The Oil shell, at least, reverted to (a forked version of) 2 after upgrading to 3. http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq
- toyg 7y ago
  How has that project not been sued into oblivion by Royal Dutch Shell yet...?
jsmeaton 7y ago
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 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.
- Joeboy 7y ago
  That's all uncannily similar to my experience porting our ~350k LOC app. "It's a dirty job, but someone's got to do it".
kelnos 7y ago
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.
- toyg 7y ago
  > 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.
- JimDabell 7y ago
  > 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]. [0] https://mail.python.org/pipermail/python-dev/2017-December/151283.html https://mail.python.org/pipermail/python-dev/2017-December/1... [1] https://docs.python.org/3/library/collections.html#collections.OrderedDict https://docs.python.org/3/library/collections.html#collectio...
a1369209993 7y ago
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.
- abiogenesis 7y ago
  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.
ies7 7y ago
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.
bsder 7y ago
The same reasons that an even larger codebase never upgraded from Visual Basic 6.
takeda 7y ago
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.

TylerE 7y ago

Because giant codebase that would take effort++++ to do so for no perceived gain, with possible addition of new bugs.

mywittyname 7y ago
> effort++++ effort += 1 + 1 Ported to Python3 for you.
- moonchild 7y ago
  Correction: effort = (effort := effort + 1) + 1
  - pansa2 7y ago
    Executable pseudocode!
- nxpnsv 7y ago
  Clearly c got it wrong. The number of + should have been increment so e->e + 1 should be e+ e+->e+ +1 should be e++ ...
imtringued 7y ago
That's how we get decades old cobol codebases that nobody understands.

jefft255 7y ago

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!!

6gvONxR4sf7o 7y ago
In some ways that's the whole point of code. You want to get to forget about it doing all these things without you.
- takeda 7y ago
  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.
JimDabell 7y ago
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.

malkia 7y ago

Many internal tools for one, platforms, etc. Hard to tell. One industry example is https://vfxplatform.com/ 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.

takeda 7y ago
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.
- orionblastar 7y ago
  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.
  - takeda 7y ago
    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.

vharuck 7y ago

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.

falcolas 7y ago

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.

wiredfool 7y ago

Personally, the main software I use at $DAY_JOB doesn't support python 3 yet. I'm not looking forward to the scramble when it does upgrade, as we're using a ton of community modules that may or may not be abandoned.

Animats 7y ago

Some of the older hosting services still support only Python 2, or some early crappy version of Python 3.

mehrdadn 7y ago

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

abathur 7y ago

The Oil shell, at least, reverted to (a forked version of) 2 after upgrading to 3. http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq

toyg 7y ago
How has that project not been sued into oblivion by Royal Dutch Shell yet...?

jsmeaton 7y ago

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

Joeboy 7y ago
That's all uncannily similar to my experience porting our ~350k LOC app. "It's a dirty job, but someone's got to do it".

kelnos 7y ago

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.

toyg 7y ago
> 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.
JimDabell 7y ago
> 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]. [0] https://mail.python.org/pipermail/python-dev/2017-December/151283.html https://mail.python.org/pipermail/python-dev/2017-December/1... [1] https://docs.python.org/3/library/collections.html#collections.OrderedDict https://docs.python.org/3/library/collections.html#collectio...

a1369209993 7y ago

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.

abiogenesis 7y ago
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.

ies7 7y ago

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.

bsder 7y ago

The same reasons that an even larger codebase never upgraded from Visual Basic 6.

takeda 7y ago

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.