On 23May2019 0947, Anders Munch wrote: > Fra: Paul Moore [mailto:p.f.moore at gmail.com]: >>> A major version change serves as a heads up that something is going on and you need to check the consequences before upgrading. >> Python's backward compatibility policy allows breaking changes between versions X.Y and X.Y+1 (with a suitable deprecation period). This proposal is no different. > > Except perhaps in scale. The same people that upgrade from 3.x to 3.x+1 without giving it a second thought, just to be on the latest version, will hesitate to go from 3.x to 4.y, because the major version change is a hint that they should be more careful. That means they're ready for it when they get the ModuleNotFoundError exception, instead of feeling ambushed. > > OK, it may be that this is not enough to warrant a 4.0 release, but I do think python-dev should get over its fear of major versions sometime. And that transitioning to a leaner standard library with some things moved to PyPI would not be a bad program statement for a Python 4.0. We need to make it more clear somehow that Python uses series.major.minor.micro versioning, not SemVer. I see this confusion happen all the time. Think of it as Python3 7.x moving to Python3 8.x, and evaluate how much effort you should put into migration :) That said, I'm totally in favour of Python 4.0 being the point where we change expectations about what will be in the standard library (and also C API, language/implementation semantics, etc.). But until we have a clear vision statement that everyone (or enough) is behind, there's nothing gained by prematurely causing that much disruption. Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4