Re: Why Python 4.0 won't be like Python 3.0
On 2014-08-19, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Grant Edwards wrote: On 2014-08-18, Ethan Furman et...@stoneleaf.us wrote: On 08/18/2014 07:51 AM, Grant Edwards wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Even our own 3.0 was like that. So was 2.0, only it wasn't quite as distruptive as 3.0. How was it disruptive? It was as backward compatible to 1.5 as any point release can be expected to be. There were syntax changes, but they added new syntax, and didn't take anything away. In my opinion, 2.6 was a bigger change than 2.0 from the perspective of backwards compatibility. 2.6 finally made raising from strings an error. I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff. I do remember delaying moving from 1.5.2 - 2.0 until I really had to, but I don't remember why. -- Grant Edwards grant.b.edwardsYow! Oh, I get it!! at The BEACH goes on, huh, gmail.comSONNY?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards invalid@invalid.invalid wrote: I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff. I do remember delaying moving from 1.5.2 - 2.0 until I really had to, but I don't remember why. If you were a RedHat user during that timeframe, that might have contributed to your decision to delay. I no longer remember the details, but it was rather painful. Skip P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems kind of unfriendly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 2014-08-19, Skip Montanaro s...@pobox.com wrote: On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards invalid@invalid.invalid wrote: I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff. I do remember delaying moving from 1.5.2 - 2.0 until I really had to, but I don't remember why. If you were a RedHat user during that timeframe, that might have contributed to your decision to delay. I no longer remember the details, but it was rather painful. Skip P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems kind of unfriendly. Many, many years ago it was an attept to reduce spam and to avoid receiving copies of followups. There used to be a fair number of Usenet and mailing-list users who seemed to think that their followups were so important that they would not only post it to the group (or mail it to the mailing list), they would also send you a copy directly. I got tired of messing with procmail filters to try to eliminate those, so I finally removed my e-mail address from the headers. If people want to e-mail me, my address is below. -- Grant Edwards grant.b.edwardsYow! Vote for ME -- I'm at well-tapered, half-cocked, gmail.comill-conceived and TAX-DEFERRED! -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Skip Montanaro s...@pobox.com writes: On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards invalid@invalid.invalid wrote: I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff. I do remember delaying moving from 1.5.2 - 2.0 until I really had to, but I don't remember why. If you were a RedHat user during that timeframe, that might have contributed to your decision to delay. I no longer remember the details, but it was rather painful. I vaguely remember holding off for a while until SWIG had 2.0 support, or maybe Numeric lagged, or something, but that's getting pretty fuzzy. There was definitely more there than, say, for 1.4 to 1.5. It's hard to believe that the Dubois/Hinsen/Hugunin article in Computers in Physics (which was where I got my start with python) was a full 18 years ago. Cheers, Johann -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Grant Edwards wrote: I do remember delaying moving from 1.5.2 - 2.0 until I really had to, but I don't remember why. I remember delaying moving from 1.5 until 2.3, but I remember why. Three reasons: (1) People are often like cats, and like cats, they are either curious and inquisitive about anything new (ooh, shiny! is it good to play with???) or suspicious and fearful of anything new (it's different, I don't like it). I happened to be going through a stage of my life closer to the second than the first at the time. (2) I was reluctant to install software by hand if it wasn't handled by my system's package manager. I still am, but not as reluctant as I was back then. (3) I was still learning the language, and all the books I had on Python covered 1.5. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 2014-08-17, Mark Lawrence breamore...@yahoo.co.uk wrote: A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. I don't think one (or several) blog posts is going to change the perceptions and expectations that have been coditioned into us by decades of experience with x.0 versions of countless software packages. If it's just another in a a series of incremental bug fix and minor enhancements without breaking backwards incompatibility releases, you simply do not call it vers x.0. -- Grant Edwards grant.b.edwardsYow! Bo Derek ruined at my life! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Tue, Aug 19, 2014 at 12:51 AM, Grant Edwards invalid@invalid.invalid wrote: I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. Agreed. However, by the time 3.9 comes out, there'll have been all those years of changes. The version after 3.9 would be a good time to remove stuff that's been deprecated since 3.3 or 3.6 or whatever; technically, that's breaking backward compat (hence 4.0 rather than 3.10), but in effect, it's no more breakage than a minor release would give you (since you should have stopped using deprecated APIs several versions ago). So there's still value in going to 4.0 around about ten versions after 3.0; but it doesn't necessarily have to happen exactly then. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Grant Edwards invalid@invalid.invalid wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Three shall be the number thou shalt count, and the number of the counting shall be three, no more, no less. .. https://www.youtube.com/watch?v=xOrgLj9lOwk (1:30) Or lets make the version asymptotically grow towards 4. Any sensible function for that? --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 08/18/2014 07:51 AM, Grant Edwards wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Even our own 3.0 was like that. I don't think one (or several) blog posts is going to change the perceptions and expectations that have been coditioned into us by decades of experience with x.0 versions of countless software packages. If it's just another in a a series of incremental bug fix and minor enhancements without breaking backwards incompatibility releases, you simply do not call it vers x.0. Yup. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 08/18/2014 10:00 AM, ElChino wrote: Grant Edwards invalid@invalid.invalid wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Three shall be the number thou shalt count, and the number of the counting shall be three, no more, no less. .. https://www.youtube.com/watch?v=xOrgLj9lOwk (1:30) Right. 5.0 it is, then. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 2014-08-18, Ethan Furman et...@stoneleaf.us wrote: On 08/18/2014 07:51 AM, Grant Edwards wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Even our own 3.0 was like that. So was 2.0, only it wasn't quite as distruptive as 3.0. Don't get me started on the RedHat [5678].0 OS releases from back in the day... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 8/18/2014 2:09 PM, Grant Edwards wrote: On 2014-08-18, Ethan Furman et...@stoneleaf.us wrote: On 08/18/2014 07:51 AM, Grant Edwards wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Even our own 3.0 was like that. So was 2.0, only it wasn't quite as distruptive as 3.0. As I recall, 2.0 _was_ 1.6. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Grant Edwards invalid@invalid.invalid writes: I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. This consensus is sometimes termed “semantic versioning”, that is, giving semantic meaning to the structural elements of a version string URL:http://semver.org/. I'm glad someone has taken the time to codify that sensible and useful de-facto standard for version strings. I don't think one (or several) blog posts is going to change the perceptions and expectations that have been coditioned into us by decades of experience with x.0 versions of countless software packages. If it's just another in a a series of incremental bug fix and minor enhancements without breaking backwards incompatibility releases, you simply do not call it vers x.0. Agreed. The convention is well established and rogues deviate from it at the peril of unnecessary confusion. -- \ “Guaranteed to work throughout its useful life.” —packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Tue, Aug 19, 2014 at 3:00 AM, ElChino elch...@cnn.cn wrote: Or lets make the version asymptotically grow towards 4. Any sensible function for that? Easy! We just keep on adding parts. 3.7, 3.8, 3.9, 3.9.9, 3.9.9.9, 3.9.9.9.9, 3.9.9.9.9.9... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Grant Edwards wrote: On 2014-08-17, Mark Lawrence breamore...@yahoo.co.uk wrote: A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. I consider versions to be *strings*. They include non-numeric components such as a, b, rc, so they aren't numbers. They're certainly not floating point numbers, since they have a variable number of decimal points. Although there is at least one unofficial standard for interpreting version numbers (semantic versioning), the most popular by far is whatever I mean by it today and the only reasonable interpretation of an arbitrary software package's version number is as free-form text. Given two version numbers for the same arbitrary package, X and Y, just about the only thing you can be sure of is that if X Y, Y is *probably* newer. To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. *All* of us? So... you're not a user of the Linux kernel? http://www.linuxplanet.com/news/goodbye-linux-2.6-hello-linux-3.0.html Or Java 5, 6, 7, 8. http://en.wikipedia.org/wiki/Java_version_history Or Firefox. https://support.mozilla.org/en-US/questions/956361 (I believe that Firefox is now up to version 31, with version 32 due at 3:00pm and 33 due at 5:30pm.) And not a Mac user either, I imagine, since Mac OS introduces major backward incompatible changes to point releases. Mac OS version X tends to prefer version *names* rather than numbers: http://en.wikipedia.org/wiki/History_of_OS_X which Debian-based Linux distros also tend to follow. Or for that matter, not a Python user either: https://docs.python.org/dev/whatsnew/2.0.html Version 4.0, when it comes out, will merely be a return to past practices in Python-land, which are quite similar to practices in many major software packages. Version 3.0 was the anomaly. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Grant Edwards wrote: On 2014-08-18, Ethan Furman et...@stoneleaf.us wrote: On 08/18/2014 07:51 AM, Grant Edwards wrote: To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. Even our own 3.0 was like that. So was 2.0, only it wasn't quite as distruptive as 3.0. How was it disruptive? It was as backward compatible to 1.5 as any point release can be expected to be. There were syntax changes, but they added new syntax, and didn't take anything away. In my opinion, 2.6 was a bigger change than 2.0 from the perspective of backwards compatibility. 2.6 finally made raising from strings an error. # 2.4 py raise hello Traceback (most recent call last): File stdin, line 1, in ? hello # 2.6 py raise hello Traceback (most recent call last): File stdin, line 1, in module TypeError: exceptions must be old-style classes or derived from BaseException, not str (I make no comment about the quality of 2.0 versus 2.0.1 :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Tue, Aug 19, 2014 at 10:05 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I consider versions to be *strings*. They include non-numeric components such as a, b, rc, so they aren't numbers. They're certainly not floating point numbers, since they have a variable number of decimal points. Although there is at least one unofficial standard for interpreting version numbers (semantic versioning), the most popular by far is whatever I mean by it today and the only reasonable interpretation of an arbitrary software package's version number is as free-form text. Given two version numbers for the same arbitrary package, X and Y, just about the only thing you can be sure of is that if X Y, Y is *probably* newer. Let's say version identifiers. The point of schemes like semver.org is to make it possible to define the X Y inequality between two such identifiers. (There are similar schemes, such as that used by Debian's package management. They're often broadly compatible.) Or Java 5, 6, 7, 8. http://en.wikipedia.org/wiki/Java_version_history Are they major versions, or 1.5, 1.6, 1.7, 1.8? Or both? Or Firefox. https://support.mozilla.org/en-US/questions/956361 (I believe that Firefox is now up to version 31, with version 32 due at 3:00pm and 33 due at 5:30pm.) So true. And not a Mac user either, I imagine, since Mac OS introduces major backward incompatible changes to point releases. Mac OS version X tends to prefer version *names* rather than numbers: http://en.wikipedia.org/wiki/History_of_OS_X which Debian-based Linux distros also tend to follow. With Debian distros, there is a version number as well as the name - Wheezy (current stable) is Debian 7, currently showing 7.5, and the previous version (Squeeze) is Debian 6. This more-or-less follows the standard concept of major versions, as it's at the point of a new release that breaking changes will be made. There's a broad expectation in a lot of communities that the basic major.minor.rev scheme will be followed. It's definitely not universal, but it's the most popular convention by far (unless you count version numbers don't mean anything as a convention). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On 19 August 2014 00:51, Grant Edwards invalid@invalid.invalid wrote: On 2014-08-17, Mark Lawrence breamore...@yahoo.co.uk wrote: A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. To all of us out here in user-land a change in the first value in the version tuple means breakage and incompatibilities. And when the second value is 0, you avoid it until some other sucker has found the bugs and a few more minor releases have come out. No. A major version increase *may* introduce breakage and incompatibilities. It does not mean that it *has* to introduce breakage and incompatibilities. If the major version increase is documented as just being the next version then there's no reason to avoid it - unless your policy is wait for the first patch release i.e. never take major.minor.0 but always wait for major.minor.1. What is more important is that minor and patch version increases should avoid introducing breakage and incompatibilities wherever possible (security fixes are one reason to allow incompatibility in a minor release). BTW I agree with the idea that 4.0 would be an appropriate time to remove anything that has been deprecated for the requisite number of versions. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
Ben Finney wrote: Grant Edwards invalid@invalid.invalid writes: I agree with the comments that the appellation for simply the next version after 3.9 should be 3.10 and not 4.0. Everybody I know considers SW versions numbers to be dot-separated tuples, not floating point numbers. This consensus is sometimes termed “semantic versioning”, that is, giving semantic meaning to the structural elements of a version string URL:http://semver.org/. I'm glad someone has taken the time to codify that sensible and useful de-facto standard for version strings. I don't think one (or several) blog posts is going to change the perceptions and expectations that have been coditioned into us by decades of experience with x.0 versions of countless software packages. If it's just another in a a series of incremental bug fix and minor enhancements without breaking backwards incompatibility releases, you simply do not call it vers x.0. Agreed. The convention is well established Only if you ignore the vast majority of software which does not follow that convention. Having *any* semantics to version numbers at all, apart from bump the version number when you feel like it, is the exception rather than the rule. Probably the most common version numbering system is the date I last remembered to update the version number, or a simple incrementing counter. (It's a version *number*, not a version tuple.) It is amazing how well-established a convention can appear if you ignore the exceptions to it and consider only a sufficiently narrow niche, like some of the FOSS software I'm familiar with. and rogues deviate from it at the peril of unnecessary confusion. Rogues like Python, the Linux kernel, Oracle, Mozilla, Haskell, ... Well, okay, Oracle are rogues. But not because of their version numbering. I find it amusing that Haskell uses a versioning number scheme that uses two dot-separated major versions specifically to combat the emotional reaction to major-version changes exhibited in this thread by Grant. With Haskell, changing from (say) 0.6.3.2 - 0.7.0.0 is a major API-breaking upgrade, but it avoids the emotional reaction of having to go from 6.3.2 - 7.0.0. http://www.haskell.org/haskellwiki/Package_versioning_policy Haskell also explicitly prohibits the useful practice of including version tags like a, b, rc *because some tools couldn't sort them correctly*. (This reminds me of those who advocate spaces over tabs, because some tools can't deal with tabs correctly.) Rather than fix the tools, the Haskell community removed non-numeric tags from the specification. On the other hand, Oracle and Sun before them take the attitude that a jump in Java's version number from 5 to 6 to 7 are only minor release changes, and the Java community is quite happy to agree. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Aug 17, 2014, at 8:37 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list Definitely a relief. After delving into Python only a few short months ago, everything I was reading suggested 2.x.x. When I switched to another book to continue with my studies, some of the code wasn't working ... welcome to 3.x.x. Needless to say, I'm using 3.4.1 exclusively today unless something bizarre requires me to do otherwise. Thanks for sharing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Mon, Aug 18, 2014 at 9:17 AM, Redge @ Versalytics.com versalyt...@gmail.com wrote: Definitely a relief. After delving into Python only a few short months ago, everything I was reading suggested 2.x.x. When I switched to another book to continue with my studies, some of the code wasn't working ... welcome to 3.x.x. Needless to say, I'm using 3.4.1 exclusively today unless something bizarre requires me to do otherwise. Good move. You should be able to upgrade to 3.4.x safely, and 3.5 fairly safely. Eventually, books about Python 3 will be the more easily found, and you won't have this kind of confusion. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
