Re: [Python-ideas] Proposal to change Python version release cycle

On Tue, Nov 7, 2017 at 4:52 AM, Nick Coghlan wrote: > Yes, going with "3.10", but encoding it as "3A" in lexically ambiguous > contexts is another option that would let us get as far as 3.35 (aka > "3Z") before encountering ambiguity problems. > No way. I call YAGNI on

Re: [Python-ideas] Proposal to change Python version release cycle

On 6 November 2017 at 22:19, Stephan Houben wrote: > 2017-11-06 12:53 GMT+01:00 Brice Parent : >> I think the only problem we can reach here, not only in our lifetimes, but >> in the next years, is not Python3.10 vs Python31.0 (Python3.x will be long >>

Re: [Python-ideas] Proposal to change Python version release cycle

What a soap opera. :-) On Mon, Nov 6, 2017 at 5:22 PM, Barry Warsaw wrote: > Nick Timkovich wrote: > > > Alternative history question: if it was just 1.6 > > Guido's time machine strikes again. There was both a Python 1.6 and a > 1.6.1. > >

Re: [Python-ideas] Proposal to change Python version release cycle

Nick Timkovich wrote: > Alternative history question: if it was just 1.6 Guido's time machine strikes again. There was both a Python 1.6 and a 1.6.1. https://www.python.org/download/releases/1.6/ https://www.python.org/download/releases/1.6.1/ The "Contractual Obligation" releases. (And

Re: [Python-ideas] Proposal to change Python version release cycle

M.-A. Lemburg wrote: > The first ever major backwards incompatibility release switch we > had in Python after the great renaming of the C APIs between > Python 1.1 and 1.2 (which was only visible to C extensions and > relatively easy to fix using a compatibility header file), > was the transition

Re: [Python-ideas] Proposal to change Python version release cycle

Isn't this recent bit of discussion an argument in favor of a new stdlib module `version`? That would contain things like resolving a version tuple to an executable name (or a cross-platform piece of an executable name)? Obviously this doesn't actually answer the question of how naming should be

Re: [Python-ideas] Proposal to change Python version release cycle

2017-11-06 12:53 GMT+01:00 Brice Parent : > > I think the only problem we can reach here, not only in our lifetimes, but > in the next years, is not Python3.10 vs Python31.0 (Python3.x will be long > dead when we reach this point!), but the ordering of versions, like >

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, Nov 4, 2017, at 10:29, Wolfgang wrote: > For example the user specified python3 but I know it will be compatible > with python4 so the launcher can do something like > python3 is not found then I use python4 if available. > > ex.: > > #!/usr/bin/env py -3 If you actually try that,

Re: [Python-ideas] Proposal to change Python version release cycle

2017-11-05 21:02 GMT+01:00 Serhiy Storchaka : > But len(os.fsencode("python3⑽.dll")) != len(os.fsencode("python39.dll")). > > I think it is on Windows. os.fsencode should use UTF-16 there. ⑽ is in the BMP Presumably, non-Windows platforms wouldn't be interested in .dll files

Re: [Python-ideas] Proposal to change Python version release cycle

05.11.17 21:53, Stephan Houben пише: After python39.dll I'd expect python3A.dll . The problem will return in 3.36. Or possibly python3⑽.dll >>> len("python3⑽.dll") == len("python39.dll") True No worries, then. But len(os.fsencode("python3⑽.dll")) != len(os.fsencode("python39.dll")).

Re: [Python-ideas] Proposal to change Python version release cycle

04.11.17 17:29, Wolfgang пише: A good point but two digits minor version numbers have the possibility to break a lot code. There is a lot of stuff out where a single digit major version is assumed. Even the official Python build for windows with python27.dll, python36.dll can be problematic

Re: [Python-ideas] Proposal to change Python version release cycle

On 2017-11-05 03:07, Nick Coghlan wrote: On 5 November 2017 at 01:29, Wolfgang wrote: On 04.11.2017 16:01, Nick Coghlan wrote: We're currently more likely to go the other direction, and stick with the 3.x numbering for an extended period (potentially reaching 3.10, 3.11,

Re: [Python-ideas] Proposal to change Python version release cycle

On 04.11.2017 20:33, Nick Timkovich wrote: > On Sat, Nov 4, 2017 at 10:44 AM, M.-A. Lemburg wrote: > >> Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing >> department thought it was good idea, not because there were major >> incompatible changes going into

Re: [Python-ideas] Proposal to change Python version release cycle

On 04/11/2017 13:29, Antoine Pitrou wrote: > > Hello Wolfgang, > > On Sat, 4 Nov 2017 12:25:57 +0100 (CET) > tds...@mailbox.org wrote: >> Hello, >> >> one of my long standing ideas to improve Python is to adjust the >> release cycle and version number handling. In short, to simplify it. > >

Re: [Python-ideas] Proposal to change Python version release cycle

On 5 November 2017 at 01:29, Wolfgang wrote: > On 04.11.2017 16:01, Nick Coghlan wrote: >> We're currently more likely to go the other direction, and stick with >> the 3.x numbering for an extended period (potentially reaching 3.10, >> 3.11, 3.12, etc), so that the ongoing

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, Nov 4, 2017 at 10:44 AM, M.-A. Lemburg wrote: > Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing > department thought it was good idea, not because there were major > incompatible changes going into that release. > Alternative history question: if

Re: [Python-ideas] Proposal to change Python version release cycle

Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing department thought it was good idea, not because there were major incompatible changes going into that release. Porting code from Python 1.5.2 to 2.0 was relatively straight forward and not much different from other minor

Re: [Python-ideas] Proposal to change Python version release cycle

On Sun, Nov 5, 2017 at 2:29 AM, Wolfgang wrote: > A good point but two digits minor version numbers have the possibility > to break a lot code. There is a lot of stuff out where a single digit > major version is assumed. Even the official Python build for windows > with

Re: [Python-ideas] Proposal to change Python version release cycle

On 04.11.2017 16:44, M.-A. Lemburg wrote: Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing department thought it was good idea, not because there were major incompatible changes going into that release. Porting code from Python 1.5.2 to 2.0 was relatively straight forward

Re: [Python-ideas] Proposal to change Python version release cycle

Hi Nick, On 04.11.2017 16:01, Nick Coghlan wrote: On 5 November 2017 at 00:40, Wolfgang wrote: On 04.11.2017 14:29, Antoine Pitrou wrote: Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: Hello, one of my long standing ideas to

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, 4 Nov 2017 16:10:32 +0100 Wolfgang wrote: > > Another possibility is to change only the versioning > to major.minor instead of major.minor.patch. Then having > a simpler versioning scheme for other Python implementations > as only benefit (and the simplification to

Re: [Python-ideas] Proposal to change Python version release cycle

Hi Nick, On 04.11.2017 15:48, Nick Coghlan wrote: On 4 November 2017 at 23:29, Antoine Pitrou wrote: Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: Hello, one of my long standing ideas to improve Python is to adjust the release cycle

Re: [Python-ideas] Proposal to change Python version release cycle

On 5 November 2017 at 00:40, Wolfgang wrote: > > > On 04.11.2017 14:29, Antoine Pitrou wrote: >> >> >> Hello Wolfgang, >> >> On Sat, 4 Nov 2017 12:25:57 +0100 (CET) >> tds...@mailbox.org wrote: >>> >>> Hello, >>> >>> one of my long standing ideas to improve Python is to adjust

Re: [Python-ideas] Proposal to change Python version release cycle

On 4 November 2017 at 23:29, Antoine Pitrou wrote: > > Hello Wolfgang, > > On Sat, 4 Nov 2017 12:25:57 +0100 (CET) > tds...@mailbox.org wrote: >> Hello, >> >> one of my long standing ideas to improve Python is to adjust the >> release cycle and version number handling. In

Re: [Python-ideas] Proposal to change Python version release cycle

On 04.11.2017 14:29, Antoine Pitrou wrote: Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: Hello, one of my long standing ideas to improve Python is to adjust the release cycle and version number handling. In short, to simplify it. There has been ample

Re: [Python-ideas] Proposal to change Python version release cycle

Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: > Hello, > > one of my long standing ideas to improve Python is to adjust the > release cycle and version number handling. In short, to simplify it. There has been ample discussion in the past about changing our

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, Nov 4, 2017 at 11:00 PM, Wolfgang wrote: > > > On 04.11.2017 12:35, Chris Angelico wrote: >> >> On Sat, Nov 4, 2017 at 10:25 PM, wrote: >>> >>> I suggest to change this to increment the major version for every new >>> release >>> of the 1,5 year

Re: [Python-ideas] Proposal to change Python version release cycle

On 04.11.2017 12:35, Chris Angelico wrote: On Sat, Nov 4, 2017 at 10:25 PM, wrote: I suggest to change this to increment the major version for every new release of the 1,5 year cycle. And allow new Python standard library backward compatible changes for every minor

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, Nov 4, 2017 at 10:25 PM, wrote: > I suggest to change this to increment the major version for every new release > of the 1,5 year cycle. > And allow new Python standard library backward compatible changes for every > minor release cycle every 6 months. The usual

[Python-ideas] Proposal to change Python version release cycle

Hello, one of my long standing ideas to improve Python is to adjust the release cycle and version number handling. In short, to simplify it. This is the first draft of the idea: Proposal to change Python version release cycle === Goal