Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

61–70 of 237 posts

Re: Code that will break in Python 4

#62
post #27

Earlier quoted context omitted.

... thats stupid. Semver isn't that complicated, and everyone understands what 3.10 means.

Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not having precognition made it difficult for Python to adopt SemVer, and now that they have versioning practices in place there needs to be more than "I like SemVer" as a compelling argument for them to change. Especially since there are reasonable people who ha…

I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes.

It probably goes back further than that, and it was probably one of those "everybody knows..." kind of things, but it definitely didn't start to be a widely-known definition a measly seven years ago.

Re: Code that will break in Python 4

#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 for years.

I just wish software would take versions seriously. Please. For my sanity.

Re: Code that will break in Python 4

#64
post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

Those two statements are mutually incompatible. Python3 is a different language with different semantics.

It is possible to work in a subset of python2 and python3 that is syntactically valid under both interpreters but this is not what you are suggesting.

Re: Code that will break in Python 4

#65
post #14

Maybe Python 4 will be properly compatible with Python 2?? Kidding. But more seriously, probably good advice. Isn't "explicit" one of the Pythonic mantras? But I'm wondering if any code written today really will survive until "Python 4"?

> Maybe Python 4 will be properly compatible with Python 2??

That'd be wild. What do you call something that is even MORE backward compatible? Going retro.

Re: Code that will break in Python 4

#66
post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

> IMO Python 4 should be:

> - backwards compatible with the latest release of Python 2

> - contain all features of Python 3 in some form

I'm lost for words.

Re: Code that will break in Python 4

#67

This is a joke, right? Obviously we can't write code that will work on python 4.

Read the article again. The people in charge of Python have said they will never make the same mistake as they did with 3 again; all future versions will be backwards-compatible.

So every program you write for Python3 will also be compatible with Python4, unless you use the deficient kinds of version-checking that the linked article extols against.

Re: Code that will break in Python 4

#69

This is a joke, right? Obviously we can't write code that will work on python 4.

You can't write code that is guaranteed to work on Python 4, but you definitively can write code that is guaranteed that will not work on Python 4.

That's what this article is about, anyway. Based on the issues with Py3 I'm quite confident that switch from 3 to 4 will be similar as from 1 to 2.

Post reply on HN