On 23May2019 0947, Anders Munch wrote:
Fra: Paul Moore [mailto:p.f.mo...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
