4 ms·

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 ac

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 7y 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 7y 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 7y 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 7y 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 7y ago
  [deleted]
umanwizard 7y 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 7y 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 7y 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 7y 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.

TylerE 7y 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 7y 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 7y 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 7y 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 7y ago
[deleted]

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