Code that will break in Python 4
61–70 of 237 posts
Re: Code that will break in Python 4
#62Earlier 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…
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
#63I just wish software would take versions seriously. Please. For my sanity.
Re: Code that will break in Python 4
#64There 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…
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
#65Maybe 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"?
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
#66There 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…
> - 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
#67This is a joke, right? Obviously we can't write code that will work on python 4.
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
#68Re: Code that will break in Python 4
#69This is a joke, right? Obviously we can't write code that will 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.
Re: Code that will break in Python 4
#70Seems like this is the fault of 'six' for defining PY3 in the first place.