7 ms·

I think we need to recognize that most people/companies who stick to python 2 doesn't do it because they are being stubborn. There is a real judgment call invol

I think we need to recognize that most people/companies who stick to python 2 doesn't do it because they are being stubborn. There is a real judgment call involved. It might look strange from the outside, but maybe it really is daunting to migrate some code-bases to python 3. (I got the sarcasm)

acdha 6y ago
In my experience, it's been a number of years since the judgement call was something other than “can we avoid paying for maintenance?”. Active projects had reasons 5+ years ago but by now it's really just a question of whether your team has a handle on technical debt management or is on an unsustainable feature treadmill.
oliwarner 6y ago
Daunting? Sure, but it's also daunting jumping from branch to branch trying to find somebody to support your rusty old Python 2 installations. Or deciding to actively run on unsupported Python. Modern software isn't fire and forget. Developers who have grown up around security exploits understand that. Higher management and FORTRAN77 programmers don't. To them it's developer busywork. The real judgement being made is money and resources.
- TylerE 6y ago
  Rusty old python 2? [citation needed] I have encountered exactly zero bugs in Python 2 in production. Code doesn’t magically stop working
  - oliwarner 6y ago
    Leaving aside the bugfixes they've kept publishing for Python 2.7 (and it's rather massive standard library), how is your stack of ~100 external dependencies holding up? In my experience, most libraries are dropping Python 2 support too. Many dropped it a while ago. Your locally running, toy projects will continue to run under Python 2 indefinitely. Large [esp network-facing] projects will start to fall apart.
    - dfox 6y ago
      Many large Python 2 projects come from age when it was not exactly practical to have ~100 external dependencies and thus do not have that. It was the time when one really though about whether having external dependency for this particular shiny thing is worth the deployment hassle involved.
      - TylerE 6y ago
        Indeed. The main project I work on at the day gig is old enough that it's build on an in-house framework that predates the first public release of Django.
  - deleted 6y ago
    [deleted]
- umanwizard 6y ago
  Python 2.7 is not dead because the PSF stopped supporting it. Thinking it is would be equivalent to thinking that C is dead because Bell Labs no longer supports it. I predict that Python 2.7 will continue being supported by some capable organization for at least the next 10 years. As a lower bound, Red Hat has promised to continue supporting it for RHEL 8 customers until at least 2024.
  - oliwarner 6y ago
    This is a Tinkerbell argument, but it's accurate enough. Python 2 will exist in some form, while people believe in it enough. But as you say, that support is likely to be paid. Many deployments rely on more than a supported cpython binary. External packages and the rest of the server stack. The Python community has largely dropped Python 2 support. If you don't need that, great. If you do... Then what? You could pay people to support your entire stack. You could upgrade. It's that choice that makes Python 2 dead. You can still run Windows 2000. Doesn't mean it's not dead.
- mopsi 6y ago
  > The real judgement being made is money and resources. Unnecessary changes and the overall fragility of "modern" software takes money and other resources away from dealing with actual security issues. There's no reason why things like a library of geospatial calculations (distance between two lat/lon pairs, etc) should need constant maintenance. They could be written once and then used for decades.
  - oliwarner 6y ago
    There's every reason, if it has bugs. That's the biggest problem with the "old" ways of doing things, you simply don't know where you're vulnerable. Refusing to allocate resources to revisit old code, only to add new features is a recipe for disaster. Upgrading to Python 3 does not fix this alone, but ignoring it, and the other dependencies that you might have, and that old Redhat 7.1 box running Linux 2.4 that's all probably fine, it's just card processing, right? Nothing else has changed. The "modern" ethos is testing everything all the time. Yeah, it's a shed-load of extra stuff if it's new to your project, but it's only codifying things that you should be doing anyway, even if only seasonally. Yes, there is occasional fragility, but that's more than offset —at least in my network-facing world— by the constant stream of security fixes across my stack. Sticking your head in the sand won't protect you.
ehutch79 6y ago
I feel like if you're not moving to 3, you probably aren't going to be pushing to move parts of your codebase to async. I have code bases that will be forever stuck on 2, because they're not active projects and are archival only.
strenholme 6y ago
Here’s my real world example of some Python 2 code which will never get ported to Python 3 (and the resulting Ycombinator heated discussion): https://news.ycombinator.com/item?id=21258527 https://news.ycombinator.com/item?id=21258527

acdha 6y ago

In my experience, it's been a number of years since the judgement call was something other than “can we avoid paying for maintenance?”. Active projects had reasons 5+ years ago but by now it's really just a question of whether your team has a handle on technical debt management or is on an unsustainable feature treadmill.

oliwarner 6y ago

Daunting? Sure, but it's also daunting jumping from branch to branch trying to find somebody to support your rusty old Python 2 installations. Or deciding to actively run on unsupported Python. Modern software isn't fire and forget. Developers who have grown up around security exploits understand that. Higher management and FORTRAN77 programmers don't. To them it's developer busywork. The real judgement being made is money and resources.

TylerE 6y ago
Rusty old python 2? [citation needed] I have encountered exactly zero bugs in Python 2 in production. Code doesn’t magically stop working
- oliwarner 6y ago
  Leaving aside the bugfixes they've kept publishing for Python 2.7 (and it's rather massive standard library), how is your stack of ~100 external dependencies holding up? In my experience, most libraries are dropping Python 2 support too. Many dropped it a while ago. Your locally running, toy projects will continue to run under Python 2 indefinitely. Large [esp network-facing] projects will start to fall apart.
  - dfox 6y ago
    Many large Python 2 projects come from age when it was not exactly practical to have ~100 external dependencies and thus do not have that. It was the time when one really though about whether having external dependency for this particular shiny thing is worth the deployment hassle involved.
    - TylerE 6y ago
      Indeed. The main project I work on at the day gig is old enough that it's build on an in-house framework that predates the first public release of Django.
- deleted 6y ago
  [deleted]
umanwizard 6y ago
Python 2.7 is not dead because the PSF stopped supporting it. Thinking it is would be equivalent to thinking that C is dead because Bell Labs no longer supports it. I predict that Python 2.7 will continue being supported by some capable organization for at least the next 10 years. As a lower bound, Red Hat has promised to continue supporting it for RHEL 8 customers until at least 2024.
- oliwarner 6y ago
  This is a Tinkerbell argument, but it's accurate enough. Python 2 will exist in some form, while people believe in it enough. But as you say, that support is likely to be paid. Many deployments rely on more than a supported cpython binary. External packages and the rest of the server stack. The Python community has largely dropped Python 2 support. If you don't need that, great. If you do... Then what? You could pay people to support your entire stack. You could upgrade. It's that choice that makes Python 2 dead. You can still run Windows 2000. Doesn't mean it's not dead.
mopsi 6y ago
> The real judgement being made is money and resources. Unnecessary changes and the overall fragility of "modern" software takes money and other resources away from dealing with actual security issues. There's no reason why things like a library of geospatial calculations (distance between two lat/lon pairs, etc) should need constant maintenance. They could be written once and then used for decades.
- oliwarner 6y ago
  There's every reason, if it has bugs. That's the biggest problem with the "old" ways of doing things, you simply don't know where you're vulnerable. Refusing to allocate resources to revisit old code, only to add new features is a recipe for disaster. Upgrading to Python 3 does not fix this alone, but ignoring it, and the other dependencies that you might have, and that old Redhat 7.1 box running Linux 2.4 that's all probably fine, it's just card processing, right? Nothing else has changed. The "modern" ethos is testing everything all the time. Yeah, it's a shed-load of extra stuff if it's new to your project, but it's only codifying things that you should be doing anyway, even if only seasonally. Yes, there is occasional fragility, but that's more than offset —at least in my network-facing world— by the constant stream of security fixes across my stack. Sticking your head in the sand won't protect you.

ehutch79 6y ago

I feel like if you're not moving to 3, you probably aren't going to be pushing to move parts of your codebase to async. I have code bases that will be forever stuck on 2, because they're not active projects and are archival only.

strenholme 6y ago

Here’s my real world example of some Python 2 code which will never get ported to Python 3 (and the resulting Ycombinator heated discussion): https://news.ycombinator.com/item?id=21258527 https://news.ycombinator.com/item?id=21258527