7 ms·

Hmm, should perhaps this be worthy of a major version number bump? Yes, it's not as large or as breaking of a change as the 2.7->3.0 transition, but by removing

Hmm, should perhaps this be worthy of a major version number bump? Yes, it's not as large or as breaking of a change as the 2.7->3.0 transition, but by removing modules from the standard library, backwards compatibility is being broken. Now, perhaps most people don't use those features anymore, but for those people who do use and rely on these modules, a major version number change would be a welcome signal that their code will no longer work with the new version. But, after the initial pain of the 2.7->3.0 transition, I doubt we'll ever see another major version number jump, even if a logical use of version numbers would merit it.

enedil 7y ago
It's also quite possible, that the people who use these features use Python 2 anyway.
- mjevans 7y ago
  Does this mean we're going to have Python 2 installed on things forever? (Particularly anything that touches NNTP servers, as there's no replacement for that lib)
  - earenndil 7y ago
    Which lib?
    - anoncake 7y ago
      The one for touching NNTP servers.
  - viraptor 7y ago
    It's simple code. It can be moved to a separate package and imported with the same name.
    - u801e 7y ago
      If it's simple, then what's the point in removing it? Dealing with standard application level protocols like SMTP, NNTP, FTP, IMAP, POP, and HTTP shouldn't require installing third party packages.
      - viraptor 7y ago
        So that they can be improved / maintained. "stdlib is where packages go to die" is kind of true. You can use contact http from stdlib for example, but that's how we get urllib, urllib2, 3rd party urllib3 and requests. For the point of removing the modules, check the "rationale" part of the PEP.
        u801e 7y ago
        The original post you responded to mentioned that NNTP did not have a replacement, so I don't see how it could be improved/maintained if it's just not there anymore.
Mirioron 7y ago
Even if they don't bump up the major version number, people are probably still going to treat it as such. I think it makes sense to bump it up.
m463 7y ago
> but by removing modules from the standard library, backwards compatibility is being broken. API 101 - there is very little cost to leaving them in, but a hidden major cost to having them disappear, usually for non-developers. -- By the way, "batteries included" is one of the BEST features of python. Have you tried to fix something in your house with a "homeowner's toolkit" which is usually something like a hammer, pliers, 2 screwdrivers, a putty knife and a few more basic tools? It is REALLY tedious, like writing a C program with a few basic tools like stdio and ctypes. More languages need "batteries included", maybe like Perl. I think if the cost of deploying a script is 1, deploying it + a dependency is literally something like 100x. You have to make assumptions about all the environments the script will run in, and they are usually wrong.
- arcticbull 7y ago
  > By the way, "batteries included" is one of the BEST features of python. None of these libraries need to be nuked from existence as a result of this change. I'd wager they'll move into PyPI modules so that teams relying on them could safely continue to do so. > Have you tried to fix something in your house with a "homeowner's toolkit" which is usually something like a hammer, pliers, 2 screwdrivers, a putty knife and a few more basic tools? It is REALLY tedious, like writing a C program with a few basic tools like stdio and ctypes. That's one extreme, but I don't think that's what's being proposed. The proposed model is closer to what Rust does today, where the core is slim, opening up new potential use cases, and the more complex functionality built on top of it is left to the community to maintain. Take a look over some of the modules they're deprecating, like smtpd. What kind of standard library requires an SMTP daemon built in? That's akin to a homeowners toolkit including a planishing hammer [2] for some reason. > I think if the cost of deploying a script is 1, deploying it + a dependency is literally something like 100x. You have to make assumptions about all the environments the script will run in, and they are usually wrong. Depends on how it's done, honestly. Check out this Rust "scripting" system [1]. It has full support for third-party crates. [1] https://github.com/DanielKeep/cargo-script https://github.com/DanielKeep/cargo-script [2] https://en.wikipedia.org/wiki/Planishing https://en.wikipedia.org/wiki/Planishing
  - 7y ago
sago 7y ago
Python minor versions allow things to be removed and thus 'break backwards compatibility'. There is a process for warning of upcoming deprecation then removing it after that. For modules this is documented in PEP 4 (from 2000). Similar deprecation schedules are used by other important ecosystems such as Django. We'd be on way more than Python 3 if the major version was bumped for each one.
- nitely 7y ago
  This. There are plenty of backward incompatible changes in every minor version bump.
  - jxramos 7y ago
    I think he’s hoping they’d adopt semantic versioning, probably won’t happen. https://semver.org/spec/v2.0.0.html https://semver.org/spec/v2.0.0.html
    - anoncake 7y ago
      It's also a bad idea. Semver doesn't distinguish between removing an API that has been deprecated for a decade and Python 2->3. Or, for that matter, between removing one function and removing large parts of the standard library.
      - bauerd 7y ago
        Both are changes that will break existing code. SemVer clearly signals this. Why bother with how long something has been deprecated?
        deleted 7y ago
        [deleted]
        anoncake 7y ago
        You don't see a difference between removing a rarely-used module that has been deprecated for a decade, giving developers 10 years to replace it on the one hand and overhauling the entire language, breaking not just some but most code, on the other hand? I'm sure Python 2.7 broke compatibility, but you don't see people refusing to upgrade from 2.6 ten years after its release.
rozab 7y ago
some of these modules have actually been deprecated since before python 3.0
anoncake 7y ago
> But, after the initial pain of the 2.7->3.0 transition, I doubt we'll ever see another major version number jump, even if a logical use of version numbers would merit it. Do you think the transition would have been less painful if 3.0 had been called 2.8?
- dagw 7y ago
  If Python 2.8 had come out and failed to run almost all code written for Python 2.7 then that probably would have been truly disastrous for the language.

enedil 7y ago

It's also quite possible, that the people who use these features use Python 2 anyway.

mjevans 7y ago
Does this mean we're going to have Python 2 installed on things forever? (Particularly anything that touches NNTP servers, as there's no replacement for that lib)
- earenndil 7y ago
  Which lib?
  - anoncake 7y ago
    The one for touching NNTP servers.
- viraptor 7y ago
  It's simple code. It can be moved to a separate package and imported with the same name.
  - u801e 7y ago
    If it's simple, then what's the point in removing it? Dealing with standard application level protocols like SMTP, NNTP, FTP, IMAP, POP, and HTTP shouldn't require installing third party packages.
    - viraptor 7y ago
      So that they can be improved / maintained. "stdlib is where packages go to die" is kind of true. You can use contact http from stdlib for example, but that's how we get urllib, urllib2, 3rd party urllib3 and requests. For the point of removing the modules, check the "rationale" part of the PEP.
      - u801e 7y ago
        The original post you responded to mentioned that NNTP did not have a replacement, so I don't see how it could be improved/maintained if it's just not there anymore.

Mirioron 7y ago

Even if they don't bump up the major version number, people are probably still going to treat it as such. I think it makes sense to bump it up.

m463 7y ago

> but by removing modules from the standard library, backwards compatibility is being broken. API 101 - there is very little cost to leaving them in, but a hidden major cost to having them disappear, usually for non-developers. -- By the way, "batteries included" is one of the BEST features of python. Have you tried to fix something in your house with a "homeowner's toolkit" which is usually something like a hammer, pliers, 2 screwdrivers, a putty knife and a few more basic tools? It is REALLY tedious, like writing a C program with a few basic tools like stdio and ctypes. More languages need "batteries included", maybe like Perl. I think if the cost of deploying a script is 1, deploying it + a dependency is literally something like 100x. You have to make assumptions about all the environments the script will run in, and they are usually wrong.

arcticbull 7y ago
> By the way, "batteries included" is one of the BEST features of python. None of these libraries need to be nuked from existence as a result of this change. I'd wager they'll move into PyPI modules so that teams relying on them could safely continue to do so. > Have you tried to fix something in your house with a "homeowner's toolkit" which is usually something like a hammer, pliers, 2 screwdrivers, a putty knife and a few more basic tools? It is REALLY tedious, like writing a C program with a few basic tools like stdio and ctypes. That's one extreme, but I don't think that's what's being proposed. The proposed model is closer to what Rust does today, where the core is slim, opening up new potential use cases, and the more complex functionality built on top of it is left to the community to maintain. Take a look over some of the modules they're deprecating, like smtpd. What kind of standard library requires an SMTP daemon built in? That's akin to a homeowners toolkit including a planishing hammer [2] for some reason. > I think if the cost of deploying a script is 1, deploying it + a dependency is literally something like 100x. You have to make assumptions about all the environments the script will run in, and they are usually wrong. Depends on how it's done, honestly. Check out this Rust "scripting" system [1]. It has full support for third-party crates. [1] https://github.com/DanielKeep/cargo-script https://github.com/DanielKeep/cargo-script [2] https://en.wikipedia.org/wiki/Planishing https://en.wikipedia.org/wiki/Planishing
- 7y ago

sago 7y ago

Python minor versions allow things to be removed and thus 'break backwards compatibility'. There is a process for warning of upcoming deprecation then removing it after that. For modules this is documented in PEP 4 (from 2000). Similar deprecation schedules are used by other important ecosystems such as Django. We'd be on way more than Python 3 if the major version was bumped for each one.

nitely 7y ago
This. There are plenty of backward incompatible changes in every minor version bump.
- jxramos 7y ago
  I think he’s hoping they’d adopt semantic versioning, probably won’t happen. https://semver.org/spec/v2.0.0.html https://semver.org/spec/v2.0.0.html
  - anoncake 7y ago
    It's also a bad idea. Semver doesn't distinguish between removing an API that has been deprecated for a decade and Python 2->3. Or, for that matter, between removing one function and removing large parts of the standard library.
    - bauerd 7y ago
      Both are changes that will break existing code. SemVer clearly signals this. Why bother with how long something has been deprecated?
      - deleted 7y ago
        [deleted]
      - anoncake 7y ago
        You don't see a difference between removing a rarely-used module that has been deprecated for a decade, giving developers 10 years to replace it on the one hand and overhauling the entire language, breaking not just some but most code, on the other hand? I'm sure Python 2.7 broke compatibility, but you don't see people refusing to upgrade from 2.6 ten years after its release.

rozab 7y ago

some of these modules have actually been deprecated since before python 3.0

anoncake 7y ago

> But, after the initial pain of the 2.7->3.0 transition, I doubt we'll ever see another major version number jump, even if a logical use of version numbers would merit it. Do you think the transition would have been less painful if 3.0 had been called 2.8?

dagw 7y ago
If Python 2.8 had come out and failed to run almost all code written for Python 2.7 then that probably would have been truly disastrous for the language.