[python-committers] Python 4.0 or Python 3.10?

[Nick Coghlan]

On Wed, 26 Sep 2018 at 07:09, Brian Curtin <brian at python.org> wrote:
> On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka <storchaka at 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 2
>>
>> and 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]` or `platform.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 at gmail.com   |   Brisbane, Australia