Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Code that will break in Python 4

#221

Post by zanny »

untog wrote: post #82
zanny wrote: post #63

As someone who has had to pressure some of the most backwards companies to update their software, it is going to be the most horrible of pains, in the same way Linux 4.0 is right now, to have a pointless major version increment. Lawyers, suits, and investors shit themselves seeing that number go up when previous increments actually meant something, so when it now no longer does, it just makes my life a living hell fo…

Semantic versioning is taking versions seriously. Far more seriously than arbitrary version numbering does, anyway. Don't get me wrong, I do understand your frustration. But "previous increments actually meant something, so when it now no longer does" is just totally incorrect. Previous increments were an attempt at bundling together a series of unrelated changes into a 'thing'. What that 'thing' is varied wildly bet…

Neither Linux or Python (if 4.0 is non-breaking) are following semver.

For Linux, 2.0 was just SMP support. In defense of Linux, there has never been a backwards breaking major version increment, suits are just paranoid about the number going up randomly. They want it to have meaning, even when it does not.

For Python, 2.0 was not breaking, but 3.0 was. Now that major version has breaking significance in accordance with semver, business interests will treat it like that and make a big deal out of a 4.0, even if it is not breaking. I know this because I deal with clients paranoid about Linux 4.0 all the time, despite insistence Linux never breaks backwards compatibility.

Fundamentally neither project is adhering to semver and are using arbitrary version systems, but if you are going to do that, it would be so much nicer if they would use a two number version - major-patch - rather than having a dead major version that is meaningless. Honestly, in programming languages, Python 3 should have legitimately been a language fork like C++ is to C rather than a version increment (like Obj C is to C) - programming languages are making a bad habit of making breaking changes in a language, and while its understandable that the developers no longer want to maintain the old standard, its deceptive to call the version increment the same language since the semantics change when you make major breaking changes like that.

Re: Code that will break in Python 4

#222

Post by dilap »

colanderman wrote: post #108

The whole Python versioning fiasco is simply baffling to me as an outsider. Why not mark Python 3 modules with a tag, or different file extension, or anything , and require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code? This is e.g. how the (roughly analogous) split between C and C++ is handled, and it works fine for the most part. No bizarre polyglot code games. Edit: Just t…

yeah, the python folks lost their mind around the 2/3 split. source: ex-python user.

Re: Code that will break in Python 4

#225

Post by phyzome »

collinmanderson wrote: post #125
bhaak wrote: post #15

Six is called the "Python 2 and 3 Compatibility Library" for a reason. I'm certain that when Python 4 will be released six will be updated so that six.PY3 will include Python 4. Of course, this opens the opportunity for two other compatibility libraries. "twelve" will be for supporting Python 3 and 4 and "twentyfour" will support Python 2, 3, and 4 at once (I hope nobody will seriously consider a library called "eigh…

Currently the issue is wontfix'd: https://bitbucket.org/gutworth/six/issues/22/variable-sixpy3... I personally doubt the author's statement: "six will be long dead and forgotten by the time Python 4 rolls around."

Yeah. Software never dies, it just gets more unpleasant to deal with.

Re: Code that will break in Python 4

#226

Post by phyzome »

mioelnir wrote: post #164
kasbah wrote: post #54

Reminds me of when Linus tagged Linux 3.0 and it broke a bunch of peoples code due to their bad version checks. Linux 2.x had been going for about 15 years.

When FreeBSD 9 was released, and the development tree thus became FreeBSD 10, a lot of applications broke. GNU autotools considered a FreeBSD version number starting with 1 as FreeBSD 1. Historical note: FreeBSD1 was rebased after the AT&T lawsuit on top of the unencumbered Berkeley release as FreeBSD2. To run FreeBSD1, you probably still need an AT&T UNIX license.

This is apparently also one reason Windows jumped from 8 to 10 -- "Windows 9" would have been read as "Windows 98" (or 95) by some software. :-(

Re: Code that will break in Python 4

#227

Post by wmil »

I was listening to a developer podcast and one of the hosts (Jeff Roberts?) had the right idea about version checks...

Never allow developers to read the version number. Instead have a function where they pass in the version number and get a boolean about whether or not it's supported.

It's really the only way to avoid code problems like this.

Re: Code that will break in Python 4

#228

Post by quesera »

Spooky23 wrote: post #116
bitwize wrote: post #47

They could always take the Microsoft route: Python 4 will be internally versioned as Python 3.1 to avoid this sort of problem.

How about the Sun route? Solaris 2.7 vs. SunOS 5.7

Even more fun..

  SunOS 4.1.4 was retroactively renamed Solaris 1.1.2.
  
  SunOS 5.6 was Solaris 2.6, but
  SunOS 5.7 was Solaris 7.
To Sun's eternal credit, they were smart about keeping the internal versioning and the marketing versioning separate.

Even to this day, so far, Oracle hasn't messed with "SunOS".

Re: Code that will break in Python 4

#229

Post by yoklov »

colanderman wrote: post #142
rogerbinns wrote: post #131

Earlier quoted context omitted.

Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working? You can easily keep things separate - python 2 executable is named python while python 3 is python3. https://www.python.org/dev/peps/pep-0397/ Sadly concurrent running in the same interpreter won't work because Python 3 has different types for strings (unicode only) and a bytes…

Yes, that is what I expect. The various flavors of C and C++ get along just fine that way. C++ is not a superset of C: http://stackoverflow.com/a/1201840/270610 C and C++ have a similar issue with strings. C code uses NUL-terminated char arrays, while C++ generally uses std::string. If you want to interface the two, you need glue code (written in C++). Surely Python 3 can work the same way: to share strings between a…

Except that you can easily go from std::string to cstring and back in the same program. And many of the standard library functions work fine on c strings (probably over half of ), etc. IMO theres no compatibility issue between std::string and c strings.
Post reply on HN