Python 4.0 or Python 3.10?
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this.
Yury
Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
Many people have bad memories of the Py2->3 transition, so I think we should avoid triggering their sensitivities by announcing a Py4 if there's nothing, in terms of changes, to justify the jump.
So my preference would be on 3.10.
Regards
Antoine.
On Sep 25, 2018, at 15:31, Antoine Pitrou <antoine@python.org> wrote:
So my preference would be on 3.10.
3.9 + 0.1 :)
Renaming it to Python 4 is fraught with knock-on effects, so I think we do reserve that for major changes. I doubt we’ll ever need for a disruptive backward incompatible change *at the Python level* in a Python 4, but I absolutely can see the possibility of incompatible changes at the public C API layer. I’m not saying it *will* happen, but that’s what we should reserve “Python 4” for if or when it happens.
-Barry
25.09.18 22:40, Barry Warsaw пише:
On Sep 25, 2018, at 15:31, Antoine Pitrou <antoine@python.org> wrote:
So my preference would be on 3.10. 3.9 + 0.1 :)
Renaming it to Python 4 is fraught with knock-on effects, so I think we do reserve that for major changes. I doubt we’ll ever need for a disruptive backward incompatible change *at the Python level* in a Python 4, but I absolutely can see the possibility of incompatible changes at the public C API layer. I’m not saying it *will* happen, but that’s what we should reserve “Python 4” for if or when it happens.
I concur.
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.
On Tue, Sep 25, 2018 at 4: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.
I think this is the last nail in the coffin of the "Python 4.0 after 3.9" idea.
Seems that we've reached the consensus: we release Python 3.10 after Python 3.9. We maybe release Python 4.0 at some point if there's a significant backwards incompatible change.
Yury
On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
On Sep 25, 2018, at 15:31, Antoine Pitrou <antoine@python.org> wrote:
So my preference would be on 3.10. 3.9 + 0.1 :)
Renaming it to Python 4 is fraught with knock-on effects, so I think we do reserve that for major changes. I doubt we’ll ever need for a disruptive backward incompatible change *at the Python level* in a Python 4, but I absolutely can see the possibility of incompatible changes at the
25.09.18 22:40, Barry Warsaw пише: public C API layer. I’m not saying it *will* happen, but that’s what we should reserve “Python 4” for if or when it happens.
I concur.
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] or platform.python_version() instead of the
alternatives that are better suited to getting specific parts of the
version.
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
Serhiy:
And changing the major version number itself is significant breaking change. From the name of the executable (python3 vs python4) hardcoded in Python
IMHO It's time to discuss again modifying the "python" program to always point to the latest Python version.
What is the status of Brett's UNIX Python launcher "py" by the way?
Victor
On Sep 25, 2018, at 18:57, Victor Stinner <vstinner@redhat.com> wrote:
IMHO It's time to discuss again modifying the "python" program to always point to the latest Python version.
This just came up again on linux-sig, but...
What is the status of Brett's UNIX Python launcher "py" by the way?
...I forgot to mention this.
FWIW, I still think we shouldn’t recommend a change here until 2.7 is done and done. However, the launcher might be a good way out.
-Barry
On Tue, 25 Sep 2018 at 15:58, Victor Stinner <vstinner@redhat.com> wrote:
Serhiy:
And changing the major version number itself is significant breaking change. From the name of the executable (python3 vs python4) hardcoded in Python
IMHO It's time to discuss again modifying the "python" program to always point to the latest Python version.
What is the status of Brett's UNIX Python launcher "py" by the way?
You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :)
On Wed, Sep 26, 2018 at 12:28 PM Brett Cannon <brett@python.org> wrote: [..]
What is the status of Brett's UNIX Python launcher "py" by the way?
You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :)
Looks like it's possible to either request a specific version (e.g. 3.6), or a major version (e.g. any Python 3). Is it possible to request "3.6 or greater (be it Python 3.10 or Python 4.0+)"?
Yury
On Wed, 26 Sep 2018 at 18:15, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On Wed, Sep 26, 2018 at 12:28 PM Brett Cannon <brett@python.org> wrote: [..]
What is the status of Brett's UNIX Python launcher "py" by the way?
You can see the current TODO list at https://crates.io/crates/python-launcher . Basically I need to implement "--help" and "--list" to fill in the last two low-hanging fruit features, but at long as you don't need to customize the search mechanism then it's already working. And BTW it's already compatible with either 3.10 or 4.0. :)
Looks like it's possible to either request a specific version (e.g. 3.6), or a major version (e.g. any Python 3). Is it possible to request "3.6 or greater (be it Python 3.10 or Python 4.0+)"?
That's not possible for the Windows launcher. As the idea is to have a uniform interface for the Windows and Unix launchers, I'd assume that this would need to be a feature request for both the Windows and Unix launchers. (It's a reasonable-seeming idea, but I don't know how useful it would be in practice - can you give some examples of use cases?)
Paul
On Wed, Sep 26, 2018 at 1:25 PM Paul Moore <p.f.moore@gmail.com> wrote: [..]
but I don't know how useful it would be in practice - can you give some examples of use cases?)
It's hard to give a real life example as "py" doesn't support this, but I can imagine the following scenario: if I have a script that uses some new 3.6 feature I could probably run it from other scripts with 'py --min=3.6 myscript.py'. That way I wouldn't need to write more code or use other tools to check if the target system has a Python 3.6+ interpreter.
Yury
Since there isn't a way to do this in any fashion I never really thought about it. I think most people either set the shebang to the version of Python they want it to work with, have pip install the entry point which will also set the entry point, or assume that e.g. python3 is new enough to work.
But even setting a minimum is potentially troublesome if there's an incompatibility, e.g. you used 'async' as a variable name and suddenly you installed Python 3.7. :) So I don't know if the desire/utility of having a minimum is worth the added complexity.
On Wed, 26 Sep 2018 at 10:54, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On Wed, Sep 26, 2018 at 1:25 PM Paul Moore <p.f.moore@gmail.com> wrote: [..]
but I don't know how useful it would be in practice - can you give some examples of use cases?)
It's hard to give a real life example as "py" doesn't support this, but I can imagine the following scenario: if I have a script that uses some new 3.6 feature I could probably run it from other scripts with 'py --min=3.6 myscript.py'. That way I wouldn't need to write more code or use other tools to check if the target system has a Python 3.6+ interpreter.
Yury
On Thu, Sep 27, 2018 at 2:19 PM Brett Cannon <brett@python.org> wrote:
Since there isn't a way to do this in any fashion I never really thought about it. I think most people either set the shebang to the version of Python they want it to work with, have pip install the entry point which will also set the entry point, or assume that e.g. python3 is new enough to work.
But even setting a minimum is potentially troublesome if there's an incompatibility, e.g. you used 'async' as a variable name and suddenly you installed Python 3.7. :) So I don't know if the desire/utility of having a minimum is worth the added complexity.
I agree.
Yury
On Tue, 25 Sep 2018 at 20:32, Antoine Pitrou <antoine@python.org> wrote:
Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
Many people have bad memories of the Py2->3 transition, so I think we should avoid triggering their sensitivities by announcing a Py4 if there's nothing, in terms of changes, to justify the jump.
So my preference would be on 3.10.
I agree. 3.10 seems like the best choice. Even though we don't expect 4.0 to be a major breaking change like 3.0, people do assume something like semantic versioning, and therefore expect 3.9 -> 4.0 to be a "bigger" change than 3.9 -> 3.10.
One thing that *will* need work is places that assume single-digit version components (for example the wheel spec uses pyXY to mark compatibility with Python X.Y - that will need tweaking to allow for 3.10). IMO, we should make it clear sooner rather than later that version numbering will be going 3.8, 3.9, 3.10, 3.11, ... to give people a chance to prepare. Otherwise we might inadvertently have another major compatibility issue right after 3.9 :-( The uncertainty simply lets people assume whatever's least disruptive for them, and not be ready.
Paul
On 25.09.2018 21:30, Yury Selivanov wrote:
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
why call it 4.0 when there are no significant changes? Just calling it 4.something sends the wrong signal, that probably people try to skip 3.x and keep going with 2.7 ...
Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this.
sorry, for me that sounds like a non-decision.
On Tue, Sep 25, 2018 at 1:30 PM Yury Selivanov <yselivanov.ml@gmail.com> wrote:
What's the current plan for what version of Python we release after 3.9?
One idea I've heard is to switch to calendar versioning after 3.9. So we'd start with something like "2021" (year) or "2021.06" (year + month). sys.version_info would stay monotonic and so would the version macro in the C-API. The executable would still be "python3" so it may still make sense to incorporate "3" into the version. When we do get to a major/breaking change we'd change the executable to "python4" and incorporate "4" into the version.
Switching to calver doesn't necessarily mean we'd tie ourselves to a fixed release schedule, but doing so would probably fit better with calver. :)
Anyway, this is just something I've heard discussed which I kind of liked.
-eric
On Tue, Sep 25, 2018, 12:30 Yury Selivanov <yselivanov.ml@gmail.com> wrote:
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I don't know what we'll end up calling it, but I don't think it matters for this. For warnings about future deprecations and removals, I would use "3.10" regardless.
No one can predict the future; maybe our future selves will change their minds when we get there. But for people reading the documentation now, "3.10" clearly means "the version after 3.9", so they'll understand what you mean. And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no one can claim you didn't warn them.
OTOH if you write "4.0", at least some people will misunderstand, and be grumpy if the feature disappears in 3.10.
-n
On Tue, Sep 25, 2018 at 5:18 PM Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Sep 25, 2018, 12:30 Yury Selivanov <yselivanov.ml@gmail.com> wrote:
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I don't know what we'll end up calling it, but I don't think it matters for this. For warnings about future deprecations and removals, I would use "3.10" regardless.
No one can predict the future; maybe our future selves will change their minds when we get there. But for people reading the documentation now, "3.10" clearly means "the version after 3.9", so they'll understand what you mean. And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no one can claim you didn't warn them.
OTOH if you write "4.0", at least some people will misunderstand, and be grumpy if the feature disappears in 3.10.
Yeah, this makes sense.
Yury
2018-09-25 16:30 GMT-03:00 Yury Selivanov <yselivanov.ml@gmail.com>:
deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
On the other hand... the best chance we have to let the world know that "we will never ever again break everything as we did with the 2 to 3 transition" is to just release 4.0 after 3.9 as a simple follow up release with just the minor and usual glitches we have from minor to minor release.
IOW, we're breaking the major/minor revision evolution, but we're firmly signaling that a transition that could take a decade will not happen anymore in the future, that we learned the lesson and all evolution steps will be smooth.
See it as more a political/social decision, than a technical one.
Note 1: I remember Guido saying something like this, but to be fair I couldn't find any mail with a statement like that in a 10' exploration I just did.
Note 2: I know we planned 2.7.10 after 2.7.9, but that just reinforces my point: the idea is to communicate that we'll never have again a dead end like 2.7.
Regards,
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
Hi,
I would prefer to never ever break the backward compatibility in Python. To make it clear I suggest to use 4.0 for the release following Python 3.7.
More and more data confirm me frequently that we already reached the critical mass to declare that the migration to Python 3 is done.
There was no Python 2.8, I suggest to skip 3.8. Ten years is enough between two major versions...
To be clear, I only propose to change the version number. Not break anything. Not remove anything. Any pending removal scheduled for 4.0 must be postponed, maybe to 4.1, maybe 4.2, maybe never.
Linux switched from 3.x to 4.x and didn't break anything. We can do the same.
--
Ok, some people like me want to break the backward compatibility. You have to fight against that and make sure that incompatible changes are limited and very small per release.
Please don't use the C API as any promise of anything. This project is highly experimental and don't iffer anaything except pain at this point ;-)
Victor
Le mardi 25 septembre 2018, Yury Selivanov <yselivanov.ml@gmail.com> a écrit :
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this.
Yury
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Tue, Sep 25, 2018 at 6:33 PM Victor Stinner <vstinner@redhat.com> wrote:
Hi,
I would prefer to never ever break the backward compatibility in Python. To make it clear I suggest to use 4.0 for the release following Python 3.7.
I think Serhiy made a strong argument that the code like below would break if we release Python 4.0:
PY3 = sys.version_info[0] == 3
if not PY3:
... # implies Python 2I think we all have seen code like that; it's a common pattern. So by just bumping the version to 4.0 you would break the compatibility for some libraries and frameworks. And maybe breaking it is fine if there's a very strong technical reason, but doing that just to make a statement isn't worth it, IMHO.
Yury
On Sep 25, 2018, at 6:39 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
I think we all have seen code like that; it's a common pattern. So by just bumping the version to 4.0 you would break the compatibility for some libraries and frameworks. And maybe breaking it is fine if there's a very strong technical reason, but doing that just to make a statement isn't worth it, IMHO.
Breaking a bunch of software to make the statement that you’re not going to break backwards compatibility anymore sounds like something out of a Monty Python skit though ;)
Hi,
On 25/09/18 20:30, Yury Selivanov wrote:
What's the current plan for what version of Python we release after 3.9?
[snip]
For the record, we account for the following version tests when analysing code (on lgtm.com):
sys.version == "3" sys.version_info > (3,) sys.version_info[0] == 3 sys.version_info[:2] >= (3,0) sys.hexversion > 0x03000000
Of these forms, sys.version[0] == "3" and sys.version_info[0] == 3
will be broken by changing the major version to 4.
Personally, I prefer 3.10 to 4.0 unless there is a significant language change involved.
Cheers, Mark.
For the record, Guido prefer 3.10 to 4.0, before he retired BDFL.
https://python.zulipchat.com/#narrow/stream/116503-core/subject/rhel/near/12...
Regards,
INADA Naoki <songofacandy@gmail.com>
On 9/25/18 9:30 PM, Yury Selivanov wrote:
What's the current plan for what version of Python we release after 3.9?
The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9.
I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :)
Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this.
Yury
As someone who's still fighting every day to make people switch from "python2" (or "python") to "python3", I'd be very, very happy if I didn't have to start telling them to use "python4" instead now. Or explaining that the way to launch Python 4 is "python3". Same story with Python 2020 instead of Python 4.
(And unfortunately, a "py" launcher is not an answer here -- it won't be very useful unless it is everywhere, and that will take years in the best case.)
I'd much, much rather explain that sys.version[2] is not correct, and
solve the "python310" < "python39" problem.
On Wed, 26 Sep 2018 at 20:27, Petr Viktorin <encukou@gmail.com> wrote:
I'd much, much rather explain that
sys.version[2]is not correct, and solve the "python310" < "python39" problem.
One of the perks of the way PEP 425 deals with this [1] is that ASCII underscores sort higher than ASCII digits, so:
>>> "py31" < "py39" < "py310" < "py311"
False
>>> "py31" < "py39" < "py3_10" < "py3_11"
True(I'm not sure if that's true for all collation orders, but if we find one where it isn't, then we'd just specify a collation order to use for Python version comparisons)
Cheers, Nick.
[1] https://www.python.org/dev/peps/pep-0425/#python-tag
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (17)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Brian Curtin -
Donald Stufft -
Eric Snow -
Facundo Batista -
INADA Naoki -
Mark Shannon -
Matthias Klose -
Nathaniel Smith -
Nick Coghlan -
Paul Moore -
Petr Viktorin -
Serhiy Storchaka -
Victor Stinner -
Yury Selivanov