Mailman 3 Python 4: don't remove anything, don't break backward compatibility - Python-Dev

newer
Issue 20891 - PyGILState_Ensure on...

Python 4: don't remove anything, don't break backward compatibility

Victor Stinner

10 Mar 2014 10 Mar '14

1:55 p.m.

Hi, Last 5 years, I spend significant time to port a lot of Python 2 code on Python 3. First, using the 2to3 tool + extra manual patches. Sorry, it was not usable in practice. The conversion was very slow, it didn't fix doctests nor all other minor "details". "Fixing Python 2 code" was no always possible. I now use the six module (or a smaller subset) to port applications to Python 3. Today, they are still many dependencies blocking applications to be ported to Python 3. So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release. I don't want another six, nine or whatever module to fill the gap between Python 3 and Python 4. For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.) I mean that any incompatible change must following the classic transition plan: tag the feature as deprecated and wait at least one major version before dropping it, or just keep it forever. We can expect that just changing the major version (3 => 4) will already break enough applications (where "python3" or "version == 3" is hardcoded")... Instead of asking application developers to try to follow each major Python release, we should try to keep the maintaince pain in Python core. What do you think? Victor

Show replies by date

Barry Warsaw

10 Mar 10 Mar

2:04 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mar 10, 2014, at 02:55 PM, Victor Stinner wrote:

...

So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?

What do you think?

Just that it's crazy to be talking about Python 4 right now. We have at least 9 years before we have to worry about that. ((~3.10 - 3.4) * 18months)). -Barry

Steven D'Aprano

3:04 p.m.

On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...]

...

So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?

No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.

I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes?

...

For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.)

If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9. So, assuming no further radical changes to the language like 2->3, we'd have five more point releases before needing to deal with 4.0. Perhaps we need a long-term schedule? 3.5: August 2015 3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021 4.0: February 2023 give or take a few months. -- Steven

Stefan Richthofer

3:25 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes. The meaning of the versioning scheme is literally [API compatibility].[new features].[bug fixes], isn't it? So all you are asking for is never do produce a Python 4.x This is not necessarily bad, for instance Java has never increased its major version ever (it is still 1.7.x). An indeed, it never dropped features, just "deprecated".

...

I don't see any reason to bump the major version number until after Python 3.9.

Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Cheers Stefan

...

Gesendet: Montag, 10. März 2014 um 16:04 Uhr Von: "Steven D'Aprano" An: python-dev@python.org Betreff: Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...]

...
So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?

No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.

I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes?

...
For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.)

If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9. So, assuming no further radical changes to the language like 2->3, we'd have five more point releases before needing to deal with 4.0.

Perhaps we need a long-term schedule?

3.5: August 2015 3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021 4.0: February 2023

give or take a few months.

-- Steven _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...

Victor Stinner

3:50 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...

I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

...

Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc.

The major version is sometimes seen as the age of a project. I propose to bump Python to version 4 because people understand that Python 4 is much better than Python 3 :-) Firefox changes its major version every 4 months or something like that. I suggest to wait less than 8 years for Python 4. http://en.wikipedia.org/wiki/Software_versioning#Political_and_cultural_sign... Or maybe we should jump directly to Python 5 for asian users and to follow PHP version! http://en.wikipedia.org/wiki/Tetraphobia Victor

Brett Cannon

4:06 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote:

...

2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever.

...

...
Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc.

The major version is sometimes seen as the age of a project. I propose to bump Python to version 4 because people understand that Python 4 is much better than Python 3 :-)

Sure, but you also understand 3.5 is better than 3.4. You're also making the assumption that people are going to pick up on the fact that major version shifts from Python are suddenly not a big deal, even though it is still well known the shift from 2 to 3 was a big deal.

...

Firefox changes its major version every 4 months or something like that.

Sure, but we are not about to do 4 month release cycles. Releasing that often does make minor version numbers silly since they become double digits so quickly. But since we are not shifting from our 18 month cycle we don't have that issue; 15 years (typically) between a .0 and .9 release doesn't really lead to a worry of exhausting reasonable minor version numbers.

...

I suggest to wait less than 8 years for Python 4.

Why? What's special about 8 years?

Victor Stinner

4:08 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

...

...
I suggest to wait less than 8 years for Python 4.

Why? What's special about 8 years?

It's the time between Python 2.0 and 3.0. Victor

Brett Cannon

4:37 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon Mar 10 2014 at 12:08:55 PM, Victor Stinner wrote:

...

...
...
I suggest to wait less than 8 years for Python 4.

Why? What's special about 8 years?

It's the time between Python 2.0 and 3.0.

But I'm willing to bet that's going to be an anomaly. Python 3 came into existence when it did so we didn't wait too long for Python 2 to get even more of a foothold; the expectation is that long-term more non-Python 2 code will be written than not. There's no rush on Python 4 since there are no plans to try and tweak something as drastic as str/bytes.

Oleg Broytman

5:50 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 04:37:45PM +0000, Brett Cannon wrote:

...

On Mon Mar 10 2014 at 12:08:55 PM, Victor Stinner wrote:

...
...
...
I suggest to wait less than 8 years for Python 4.

Why? What's special about 8 years?

It's the time between Python 2.0 and 3.0.

But I'm willing to bet that's going to be an anomaly. Python 3 came into existence when it did so we didn't wait too long for Python 2 to get even more of a foothold; the expectation is that long-term more non-Python 2 code will be written than not. There's no rush on Python 4 since there are no plans to try and tweak something as drastic as str/bytes.

Well, the entire discussion is about "please don't do major changes -- we've got enough already". Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

R. David Murray

5:08 p.m.

On Mon, 10 Mar 2014 16:06:22 -0000, Brett Cannon wrote:

...

On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote:

...
2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever.

We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.) --David

Chris Angelico

5:13 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray wrote:

...

(That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

A transition from 3.9 to 4.0 that removes a whole lot of deprecated aliases and such wouldn't be a bad thing. It's technically breaking backward compat (and thus justifying the major version bump), but any code broken by it would have been unidiomatic for the past X versions anyway. ChrisA

Ryan Gonzalez

6:18 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

This is my standpoint. The major releases would remove the code that's been marked as "deprecated". You probably would've know for the past 3 versions anyway... On Mon, Mar 10, 2014 at 12:13 PM, Chris Angelico wrote:

...

On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray wrote:

...
(That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

A transition from 3.9 to 4.0 that removes a whole lot of deprecated aliases and such wouldn't be a bad thing. It's technically breaking backward compat (and thus justifying the major version bump), but any code broken by it would have been unidiomatic for the past X versions anyway.

ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

MRAB

6:21 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 2014-03-10 17:08, R. David Murray wrote:

...

On Mon, 10 Mar 2014 16:06:22 -0000, Brett Cannon wrote:

...
On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote:

...
2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever.

We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

What does "irregardless" mean?

Donald Stufft

6:24 p.m.

On Mar 10, 2014, at 2:21 PM, MRAB wrote:

...

On 2014-03-10 17:08, R. David Murray wrote:

...
On Mon, 10 Mar 2014 16:06:22 -0000, Brett Cannon wrote:

...
On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote:

...
2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever.

We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

What does "irregardless" mean?

http://www.merriam-webster.com/dictionary/irregardless

...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Eric V. Smith

6:25 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 02:21 PM, MRAB wrote:

...

On 2014-03-10 17:08, R. David Murray wrote:

...
On Mon, 10 Mar 2014 16:06:22 -0000, Brett Cannon wrote:

...
On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote:

...
2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever.

We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

What does "irregardless" mean?

Read it as "without regard to".

Ethan Furman

7:28 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 11:21 AM, MRAB wrote:

...

What does "irregardless" mean?

The same thing as "regardless", with an extra syllable just for fun. -- ~Ethan~

Mark Lawrence

10:20 p.m.

On 10/03/2014 19:28, Ethan Furman wrote:

...

On 03/10/2014 11:21 AM, MRAB wrote:

...
What does "irregardless" mean?

The same thing as "regardless", with an extra syllable just for fun.

-- ~Ethan~

Is this the UK, US, Australian or some other "regardless"? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

Greg Ewing

10:29 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

MRAB wrote:

...

What does "irregardless" mean?

It's what people say when they misunderestimate the importance of correct prefix usage in English. -- Greg

Paul Moore

6:50 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 10 March 2014 17:08, R. David Murray wrote:

...

We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.)

I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point). I do think it's a bad idea to start talking in terms of "the next big compatibility break", even if *we* know there's no immediate plan. People are very quick to pick up messages like "Now that Python 3 is out of the way, the Python devs are talking about Python 4" which is not a message we want to see getting traction. I'm neither averse to, nor in favour of, a Python 4 compatibility break in due course, but maybe we should avoid letting the idea take hold this soon. Users are still concerned about the Python 3 change, it wouldn't do any harm if they got the clear message "at least it's a one-off exercise". Paul

Serhiy Storchaka

7:42 p.m.

10.03.14 20:50, Paul Moore написав(ла):

...

I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point).

This is just an euphemism for "not in observable future".

Chris Barker

9:39 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 12:42 PM, Serhiy Storchaka wrote:

...

This is just an euphemism for "not in observable future".

is ANY of the future observable? Oh right, The Time Machine! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

Paul Moore

9:54 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 10 March 2014 19:42, Serhiy Storchaka wrote:

...

10.03.14 20:50, Paul Moore написав(ла):

...
I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point).

This is just an euphemism for "not in observable future".

I understand that - my concern is that people reading such comments out of context might not realise this ("after all, that was what Python 3000 meant, then you went and implemented it"). Paul

Stephen J. Turnbull

11 Mar 11 Mar

6:14 a.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

Paul Moore writes:

...

I understand that - my concern is that people reading such comments out of context might not realise this ("after all, that was what Python 3000 meant, then you went and implemented it").

Sure, but why worry about it? The important part of "willful ignorance" is the "willful". We can't "fix" people who are willing to accept that crap -- they'll find some other crap to believe. Python 3 already has undeniable cruft (some Python 2 compatibility stuff) and arguably some things that could have been done better but can't really be changed in Python 3 (see the backtrace thread). Python makes strong promises that those things will *not* become compatibility breaks within 3.x, even if we're pretty confident that "nobody" is using them any more, and especially not when we now just think we could have done a better job on some feature. The flip side of that is that Python 4000 is going to be mentioned as the appropriate time for changing them. If that confuses people, well, we can just unconfuse them (if that's OK with them...).

Tres Seaver

10 Mar 10 Mar

8:14 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2014 02:50 PM, Paul Moore wrote:

...

I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point).

I do think it's a bad idea to start talking in terms of "the next big compatibility break", even if *we* know there's no immediate plan. People are very quick to pick up messages like "Now that Python 3 is out of the way, the Python devs are talking about Python 4" which is not a message we want to see getting traction.

Exactly. If we can't do things sensibly / incrementally without learning from the painful lessons of the past eight years, we ought to give up on the prospect of doing language design altogether.

...

I'm neither averse to, nor in favour of, a Python 4 compatibility break in due course

I am. I don't think the community can stand another such break. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMeHRsACgkQ+gerLs4ltQ4p0QCeLWgr2/qOSHmRBLLD+Wz0/+k/ EcwAn2p4lXARRCEYhyqsDpwhq/SrVEak =ZpwN -----END PGP SIGNATURE-----

Antoine Pitrou

4:54 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, 10 Mar 2014 16:50:12 +0100 Victor Stinner wrote:

...

2014-03-10 16:25 GMT+01:00 Stefan Richthofer :

...
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes.

This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3.

...
Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc.

The major version is sometimes seen as the age of a project. I propose to bump Python to version 4 because people understand that Python 4 is much better than Python 3 :-) Firefox changes its major version every 4 months or something like that. I suggest to wait less than 8 years for Python 4.

But then, three is the number, not four, and five is right out: "First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who being naughty in My sight, shall snuff it." Regards Antoine.

Barry Warsaw

3:59 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote:

...

...
I don't see any reason to bump the major version number until after Python 3.9.

Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc.

Guido famously hates two digit minor version numbers. :) -Barry

Stefan Richthofer

4:04 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

...

Guido famously hates two digit minor version numbers. :)

This is no problem either. Simply switch to hexadecimal numbering ;)

...

Gesendet: Montag, 10. März 2014 um 16:59 Uhr Von: "Barry Warsaw" An: python-dev@python.org Betreff: Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote:

...
...
I don't see any reason to bump the major version number until after Python 3.9.

Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc.

Guido famously hates two digit minor version numbers. :)

-Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.d...

Antoine Pitrou

4:56 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote:

...

...
Guido famously hates two digit minor version numbers. :)

This is no problem either. Simply switch to hexadecimal numbering ;)

Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?). Regards Antoine.

Chris Angelico

5:06 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote:

...

On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote:

...
...
Guido famously hates two digit minor version numbers. :)

This is no problem either. Simply switch to hexadecimal numbering ;)

Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?).

Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. ChrisA

Ryan Gonzalez

6:17 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

You forgot 3., and 3.$. On Mon, Mar 10, 2014 at 12:06 PM, Chris Angelico wrote:

...

On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote:

...
On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote:

...
...
Guido famously hates two digit minor version numbers. :)

This is no problem either. Simply switch to hexadecimal numbering ;)

Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?).

Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A.

ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

Chris Angelico

7:29 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Tue, Mar 11, 2014 at 5:17 AM, Ryan Gonzalez wrote:

...

You forgot 3., and 3.$.

They're both earlier than digits. Comma is 2C and dollar is 24, I remember those from the earliest days of playing around in assembly language on an Epson PC-compatible running MS-DOS 5 :) But that's beside the point. I don't think there'd be huge problems with a 4.0 release that's just like 3.10 except that it's a little more free with removal of deprecateds. Maybe that could be the point at which 2.x compatibility is dropped, like the u"string" notation. Or maybe not :) ChrisA

Emile van Sebille

7:43 p.m.

On 3/10/2014 12:29 PM, Chris Angelico wrote:

...

I don't think there'd be huge problems with a 4.0 release that's just like 3.10 except that it's a little more free with removal of deprecateds. Maybe that could be the point at which 2.x compatibility is dropped,

... and the point at which those of us on 2.x jump over 3.x to 4.x. :) Emile

MRAB

6:19 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 2014-03-10 17:06, Chris Angelico wrote:

...

On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote:

...
On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote:

...
...
Guido famously hates two digit minor version numbers. :)

This is no problem either. Simply switch to hexadecimal numbering ;)

Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?).

Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A.

Let's stick to digits. We could move on to Devanagari or Gurmukhi digits.

Greg Ewing

10:28 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

Chris Angelico wrote:

...

Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A.

And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever! The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-( -- Greg

Mark Lawrence

10:35 p.m.

On 10/03/2014 22:28, Greg Ewing wrote:

...

Chris Angelico wrote:

...
Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A.

And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever!

The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-(

Drat, drat and double drat, you beat me to it :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

Allen Li

10:58 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

I'm not a dev, so my comment doesn't have that much weight, but it is possible to stop flooding the mailing list with idle chitchat about something mostly irrelevant and non-productive? There's nothing wrong with the current Python versioning scheme. Python 4 is not planned for the near future. I don't see anything else worthy of discussion on this topic. Allen Li On Mon, Mar 10, 2014 at 10:35:29PM +0000, Mark Lawrence wrote:

...

On 10/03/2014 22:28, Greg Ewing wrote:

...
Chris Angelico wrote:

...
Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A.

And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever!

The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-(

Drat, drat and double drat, you beat me to it :)

-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language.

Mark Lawrence

--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cyberdupo56%40gmail.com

Georg Brandl

11 Mar 11 Mar

6:47 a.m.

Am 10.03.2014 23:58, schrieb Allen Li:

...

I'm not a dev, so my comment doesn't have that much weight, but it is possible to stop flooding the mailing list with idle chitchat about something mostly irrelevant and non-productive?

There's nothing wrong with the current Python versioning scheme. Python 4 is not planned for the near future. I don't see anything else worthy of discussion on this topic.

Then you should just have a moderator lock the thread, and ... oh wait. Georg

Larry Hastings

10 Mar 10 Mar

5:58 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 08:59 AM, Barry Warsaw wrote:

...

On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote:

...
...
I don't see any reason to bump the major version number until after Python 3.9. Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Guido famously hates two digit minor version numbers. :)

Yeah, but he'll be retired by then. So shh! No wonder he doesn't use Ubuntu, //arry/

Chris Barker

3:38 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 8:04 AM, Steven D'Aprano wrote:

...

If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9.

and why even then?

...

Perhaps we need a long-term schedule?

why not: 3.5: August 2015

...

3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021

3.10: February 2023

...

3.11 August 2023 3.12 February 2024 .... version numbering is not decimal -- a bump to 4.0 should mean _something_ (Though from the above, we've got a few years before we need to worry about that!) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

Brett Cannon

4:49 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon Mar 10 2014 at 12:47:21 PM, Chris Barker wrote:

...

On Mon, Mar 10, 2014 at 8:04 AM, Steven D'Aprano wrote:

...
If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9.

and why even then?

...
Perhaps we need a long-term schedule?

why not:

3.5: August 2015

...
3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021

3.10: February 2023

...
3.11 August 2023 3.12 February 2024 ....

version numbering is not decimal -- a bump to 4.0 should mean _something_

(Though from the above, we've got a few years before we need to worry about that!)

I think it got lost in email threading, but Barry pointed out that Guido famously hates double digit version numbers (as do I, probably partially because he does after all these years =).

Tres Seaver

5:01 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2014 12:49 PM, Brett Cannon wrote:

...

I think it got lost in email threading, but Barry pointed out that Guido famously hates double digit version numbers (as do I, probably partially because he does after all these years =).

"Guido hates them" isn't an argument: its a ukase. Version numbers are tuples, not decimal fractions. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMd78wACgkQ+gerLs4ltQ4s/ACdEkOvaYjP2d9IZ4g8bVJC/OZl h8gAoIu0IY1qYAhvZQzEo9Up9swJnZ60 =7tsf -----END PGP SIGNATURE-----

"Martin v. Löwis"

6:05 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

Am 10.03.14 18:01, schrieb Tres Seaver:

...

On 03/10/2014 12:49 PM, Brett Cannon wrote:

...
I think it got lost in email threading, but Barry pointed out that Guido famously hates double digit version numbers (as do I, probably partially because he does after all these years =).

"Guido hates them" isn't an argument: its a ukase.

Indeed, it is - so obey it then :-) We live in a dictatorship, after all. Regards, Martin

Oleg Broytman

5:44 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

Hi! On Mon, Mar 10, 2014 at 04:49:44PM +0000, Brett Cannon wrote:

...

I think it got lost in email threading, but Barry pointed out that Guido famously hates double digit version numbers (as do I, probably partially because he does after all these years =).

There is one minor annoyance with double digits: $ ls -l total 16 drwx------ 2 phd phd 4096 Mar 10 21:42 3.1 drwx------ 2 phd phd 4096 Mar 10 21:42 3.10 drwx------ 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx------ 2 phd phd 4096 Mar 10 21:42 4.0 Other than that I don't see any problem, and don't see any need to jump from 3.9 to 4.0. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

Serhiy Storchaka

7:47 p.m.

10.03.14 19:44, Oleg Broytman написав(ла):

...

There is one minor annoyance with double digits:

$ ls -l total 16 drwx------ 2 phd phd 4096 Mar 10 21:42 3.1 drwx------ 2 phd phd 4096 Mar 10 21:42 3.10 drwx------ 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx------ 2 phd phd 4096 Mar 10 21:42 4.0

ls -lv

Oleg Broytman

7:57 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 09:47:32PM +0200, Serhiy Storchaka wrote:

...

10.03.14 19:44, Oleg Broytman написав(ла):

...
There is one minor annoyance with double digits:

$ ls -l total 16 drwx------ 2 phd phd 4096 Mar 10 21:42 3.1 drwx------ 2 phd phd 4096 Mar 10 21:42 3.10 drwx------ 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx------ 2 phd phd 4096 Mar 10 21:42 4.0

ls -lv

Not every filemanager can do that. Not even every ls: $ uname -a FreeBSD 9.2-RELEASE $ man ls | grep -F -- -v Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

MRAB

3:42 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 2014-03-10 15:04, Steven D'Aprano wrote:

...

On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...]

...
So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?

No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.

I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes?

You mean that backwards-incompatible changes should be limited to prime- number major versions only? :-) [snip]

Brian Curtin

3:31 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 8:55 AM, Victor Stinner wrote:

...

For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything.

People put a lot of weight behind version numbers, often much more than they should. Jumping to 4.0 would be a PR nightmare and would ultimately hurt this project as more people decide that switching to another language will solve their problem better than jumping from 2.x to 4.0. People already think 2.7 to 3.4 is enough of a burden. Please do not do this.

Mark Lawrence

3:57 p.m.

On 10/03/2014 13:55, Victor Stinner wrote:

...

So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?

I've missed the announcement about this, can we have a link please? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

Ethan Furman

4:20 p.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 06:55 AM, Victor Stinner wrote:

...

What do you think?

I think Python 4.0 will follow Python 3.9. No need to rush things [1]. -- ~Ethan~ [1] The Python 2 line ended early because we had a major paradigm shift with moving to Unicode by default. Unless we experience another major paradigm shift (which would absolutely require backwards incompatible changes), there is no need to end the 3.x line early.

Cameron Simpson

11 Mar 11 Mar

2:19 a.m.

New subject: Python 4: don't remove anything, don't break backward compatibility

On 10Mar2014 14:55, Victor Stinner wrote:

...

Last 5 years, I spend significant time to port a lot of Python 2 code on Python 3. [... troubles ...] So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.

Maybe that will be the case, when it rolls around in the ordinary sequence of things. Assuming nothing groundbreaks shows up.

...

I don't want another six, nine or whatever module to fill the gap between Python 3 and Python 4.

But this I do not understand. If 4.0 is in your vision to be a regular release, why should you care that it may be years off?

...

For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.)

Just in case this is not a joke or hyperbole: I am -1 on this. Just stick with the expected numbering scheme. If there are no incompatible but desired changes queued up by the time 4.0, perhaps that will be a normal release also. If not, perhaps it will be a good time to bite the bullet.

...

I mean that any incompatible change must following the classic transition plan: tag the feature as deprecated and wait at least one major version before dropping it, or just keep it forever. We can expect that just changing the major version (3 => 4) will already break enough applications (where "python3" or "version == 3" is hardcoded")...

I tend to spell this >= 3, etc. Maybe I'm being simplistic.

...

Instead of asking application developers to try to follow each major Python release, we should try to keep the maintaince pain in Python core.

What do you think?

I agree there shouldn't be a major porting pain release just for the sake of a number change; anything like that should need justification. But conversely, I'm dead against bringing forward version 4.0 just to break the expectation of breakage. Cheers, -- Cameron Simpson The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model. - Andrew S. Tanenbaum

3698

Age (days ago)

3699

Last active (days ago)

List overview

Download

49 comments

28 participants

participants (28)

"Martin v. Löwis"
Allen Li
Antoine Pitrou
Barry Warsaw
Brett Cannon
Brian Curtin
Cameron Simpson
Chris Angelico
Chris Barker
Donald Stufft
Emile van Sebille
Eric V. Smith
Ethan Furman
Georg Brandl
Greg Ewing
Larry Hastings
Mark Lawrence
MRAB
Oleg Broytman
Paul Moore
R. David Murray
Ryan Gonzalez
Serhiy Storchaka
Stefan Richthofer
Stephen J. Turnbull
Steven D'Aprano
Tres Seaver
Victor Stinner

Python 4: don't remove anything, don't break backward compatibility

Mark Lawrence

Emile van Sebille

Mark Lawrence

Allen Li

Mark Lawrence

Cameron Simpson

tags

participants (28)