5 ms·

That version will eventually become EOL, stop getting security patches, eventually stop compiling with the latest OpenSSL, etc. Bitrot.

diggan 2y ago
Does that matter when you just want to run "old scientific code"? Old version of libraries like OpenSSL can still be run in that context, granted you don't expose that code to the internet at large.
- lbhdc 2y ago
  Old scientific code broke for many people with the introduction of the mac m1. I would think this would be a continuing trend in the future. Staying on old versions simply isn't possible over a long period without keeping the hardware going with it too.
  - diggan 2y ago
    > Old scientific code broke for many people with the introduction of the mac m1. How could the people maintaining Python possibly avoid that? It would be up to Apple to proactively reach out to affected projects, if Apple cares about that.
    - hamandcheese 2y ago
      The way to "avoid" it is to make it easier to upgrade to the latest version of python rather than making it harder.
- dumpsterdiver 2y ago
  When the qualifier is "granted you don't expose that code to the internet" then yes, it matters.
  - diggan 2y ago
    Who finds "old scientific code" and then exposes a server running that code to the internet without any changes? Sounds like asking for trouble, but I guess we all use computers differently...
    - dumpsterdiver 2y ago
      I don't know why people do things without thinking them through, but they do. Regarding trouble, I don't think we've covered anything here that wouldn't be asking for trouble.
zahlman 2y ago
Either software is updated or it isn't. If you're worried about "bitrot" then you bear the responsibility for your end of keeping the system up to date. (Or finding a third party to do it.) API Changes occur for a reason, and it isn't reasonable to expect other developers to make security fixes to their older versions of code in perpetuity while guaranteeing that stable interface in perpetuity. They'd never get to fix anything that isn't a security issue that way. Programmer resources are limited - especially for Python, which doesn't pay the overwhelming majority of its devs (although it can afford to pay several PSF staff). Python is open source. Nothing prohibits you from forking the 2.7 codebase and adding your own security patches (or more substantial things like back-porting new OpenSSL support, or even cherry-picking backwards-compatible features from 3.x that you do like), for example. I'm happy when people criticize new features in Python. But I expect to read criticism of features based on their actual merits and consequences, not on the principle that it's new or backwards-incompatible or would cause "churn".
- hamandcheese 2y ago
  So we have this proposed change which will cause a bunch of needless churn. Then we have people saying "just don't upgrade anything if you don't want to deal with the churn" but that too is a very large burden for all the reasons I mentioned. All the reasonable adults in the room want option 3: don't do the thing that causes needless churn. > But I expect to read criticism of features based on their actual merits and consequences, not on the principle that it's new or backwards-incompatible or would cause "churn". I am honestly shocked to see this attitude. Churn is a very real consequence. Do you have no respect for the time of the countless devs who use python?
  - zahlman 2y ago
    The entire point is that proponents of the change disagree that it's "needless churn". It's bizarre to me that expecting people to improve their code incrementally is considered a disrespect for their time. The proposed change is not arbitrary - which can be seen by trying to imagine the alternate universe in which the reverse change were proposed. One can imagine a world in which `except:` were added to a Python that didn't support it, but certainly not one where it were made mandatory (whether for the `except BaseException:` case or the `except Exception:` case). I assume there are people out there who would, similarly, argue that it was "needless" to make `print` into a function (and thereby break users of the `>>file` syntax). But it demonstrably and significantly makes the language better.

diggan 2y ago

Does that matter when you just want to run "old scientific code"? Old version of libraries like OpenSSL can still be run in that context, granted you don't expose that code to the internet at large.

lbhdc 2y ago
Old scientific code broke for many people with the introduction of the mac m1. I would think this would be a continuing trend in the future. Staying on old versions simply isn't possible over a long period without keeping the hardware going with it too.
- diggan 2y ago
  > Old scientific code broke for many people with the introduction of the mac m1. How could the people maintaining Python possibly avoid that? It would be up to Apple to proactively reach out to affected projects, if Apple cares about that.
  - hamandcheese 2y ago
    The way to "avoid" it is to make it easier to upgrade to the latest version of python rather than making it harder.
dumpsterdiver 2y ago
When the qualifier is "granted you don't expose that code to the internet" then yes, it matters.
- diggan 2y ago
  Who finds "old scientific code" and then exposes a server running that code to the internet without any changes? Sounds like asking for trouble, but I guess we all use computers differently...
  - dumpsterdiver 2y ago
    I don't know why people do things without thinking them through, but they do. Regarding trouble, I don't think we've covered anything here that wouldn't be asking for trouble.

zahlman 2y ago

Either software is updated or it isn't. If you're worried about "bitrot" then you bear the responsibility for your end of keeping the system up to date. (Or finding a third party to do it.) API Changes occur for a reason, and it isn't reasonable to expect other developers to make security fixes to their older versions of code in perpetuity while guaranteeing that stable interface in perpetuity. They'd never get to fix anything that isn't a security issue that way. Programmer resources are limited - especially for Python, which doesn't pay the overwhelming majority of its devs (although it can afford to pay several PSF staff). Python is open source. Nothing prohibits you from forking the 2.7 codebase and adding your own security patches (or more substantial things like back-porting new OpenSSL support, or even cherry-picking backwards-compatible features from 3.x that you do like), for example. I'm happy when people criticize new features in Python. But I expect to read criticism of features based on their actual merits and consequences, not on the principle that it's new or backwards-incompatible or would cause "churn".

hamandcheese 2y ago
So we have this proposed change which will cause a bunch of needless churn. Then we have people saying "just don't upgrade anything if you don't want to deal with the churn" but that too is a very large burden for all the reasons I mentioned. All the reasonable adults in the room want option 3: don't do the thing that causes needless churn. > But I expect to read criticism of features based on their actual merits and consequences, not on the principle that it's new or backwards-incompatible or would cause "churn". I am honestly shocked to see this attitude. Churn is a very real consequence. Do you have no respect for the time of the countless devs who use python?
- zahlman 2y ago
  The entire point is that proponents of the change disagree that it's "needless churn". It's bizarre to me that expecting people to improve their code incrementally is considered a disrespect for their time. The proposed change is not arbitrary - which can be seen by trying to imagine the alternate universe in which the reverse change were proposed. One can imagine a world in which `except:` were added to a Python that didn't support it, but certainly not one where it were made mandatory (whether for the `except BaseException:` case or the `except Exception:` case). I assume there are people out there who would, similarly, argue that it was "needless" to make `print` into a function (and thereby break users of the `>>file` syntax). But it demonstrably and significantly makes the language better.