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 everything in this thread.
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
>> dead when we reach this point!), but the ord
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.
>
> https://www.python.org/download/releases/1.6/
> https:
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 anoth
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
Nick Coghlan wrote:
> The open question will be what we call the release after that (in late
> 2022), with the main leading contenders being "4.0" (on the grounds
> that so many changes will have accumulated since 2008's 3.0 release by
> then that it makes sense to call them different major versio
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
do
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
> (python310 < python40). But
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, you'l
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 anyway...
Stephan
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")).
___
After python39.dll I'd expect python3A.dll .
Or possibly python3⑽.dll
>>> len("python3⑽.dll") == len("python39.dll")
True
No worries, then.
Stephan
2017-11-05 20:28 GMT+01:00 Serhiy Storchaka :
> 04.11.17 17:29, Wolfgang пише:
>
>> A good point but two digits minor version numbers have the po
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 becau
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, 3.12, etc), so that th
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 that release.
>>
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.
>
> Th
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 disruption caused by the
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 it was just 1.6,
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 rele
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 python27.dll, python36.dll
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
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 improve Python is to adju
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 spell compatibility).
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 and version number ha
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 the
>>> release cycl
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 short, to simplify it.
>
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 di
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 r
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 cycle.
>>> And allow new Python standard l
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 release cycle every 6 mont
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 implication of a major ve
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
Increment
32 matches
Mail list logo
