On Wed, 26 Sep 2018 at 07:09, Brian Curtin <brian@python.org> wrote:
On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
And changing the major version number itself is significant breaking change. From the name of the executable (python3 vs python4) hardcoded in Python and shell scripts to a number of third-party scripts that contain in the best case:
PY3 = sys.version_info[0] == 3 if not PY3: ... # implies Python 2and in the worst case:
PY3 = sys.version[0] == '3'Changing the minor version number from a single-digit to a two-digits will break some software too, but I think that this breakage is smaller.
FWIW, we had a similar bump in 2015 (?) when 2.7.10 was about to come out. Moving up to two digits might break some assumptions, though users misusing things isn't really our problem. Someone out there is parsing
sys.version[:5]orplatform.python_version()instead of the alternatives that are better suited to getting specific parts of the version.
At the 2017 core dev sprint, Ezio Mellotti and I also discussed the possibility of adding a string subclass that emits warnings when used in ordered comparisons, and switching to that for the result of sys.version. It wouldn't catch all cases of inappropriate comparisons against sys.version, but it would catch a lot of them.
Either way, +1 from me for running with a 3.10 release after 3.9, such that we're well and truly clear of the Python 2 end of life when Python 4.0 comes around, and we'll have time to either introduce the py launcher, or else reintroduce the default "python" symlink, before the major version number gets bumped again.
Cheers, Nick.
P.S. Note that I say this even though we use the "X.Y" version in a lot more places than just sys.version (think filesystem paths, PyPI artifact names and tags, etc). While those do have ways of coping with 3 digit version strings (either already including an "X.Y" separator, or stating that "X_Y" should be used when "XY" would be ambiguous), we can expect actually making such a release to find latent defects in assorted different pieces of software. However, unlike the 3.x compatibility breaks, adapting software to cope with a 3.10.0 release isn't going to break support for older releases.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia