Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

131–140 of 237 posts

Re: Code that will break in Python 4

#131

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…

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 type, while Python 2 has a str type (pretty much like bytes but can also be treated as a string) and a separate unicode type. Python 2 had code that tried to do the right thing automagically with str, such as automatic promotion to unicode where it looks like you really meant a string and that is what is needed. Automatic promotion can fail, be unexpected, is hard to test and numerous other issues. That is why Python 3 was needed and why it needed to be incompatible. To have Python 2 and 3 code interoperate in the same interpreter would require another layer of automatic promotion/demotion and heuristics when data goes between the two.

C++ was explicitly defined to be a superset of C so it doesn't have these kind of issues. The analogous situation would be if C didn't distinguish between long and pointer types, and C++ did. You'd need rules for how to convert between the two worlds, trying to combine or disambiguate the types depending on which way types are going. It would be a mess.

Re: Code that will break in Python 4

#132
post #114

Earlier quoted context omitted.

Hell, the reason Windows 10 is Windows 10 is because of all the bad version checks looking for "9X"

Ha! Is that true in a documented fashion or just widely suspected? I had never heard that, but it makes perfect sense.

If you Google it, you can find plenty of articles, but this is the original source [0]. The Redditor has since deleted their account it seems.

[0] https://www.reddit.com/r/technology/comments/2hwlrk/new_wind...

Re: Code that will break in Python 4

#133
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…

The move from Python 6 to 7 will be the ultimate answer. import fortytwo

Amusingly, the Hitchhiker's Guide itself contains a different purported "factorization" of 42:

http://www.everything2.com/title/what+do+you+get+if+you+mult...

Re: Code that will break in Python 4

#134
post #66

Earlier quoted context omitted.

> 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.

Python 4 should be magic.

Maybe by that time the Python community will have figured out how to make computers (or their owners) fly when you import antigravity!

Re: Code that will break in Python 4

#135

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…

> and require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code?

The interpreter is too messy for that and the transition to Python 3 was not considered well enough. There is no hope on that front. Even if you solve everything else, the C ABI will still be broken.

Re: Code that will break in Python 4

#136

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…

I think this is fundamentally because of the Python philosophy around one-true-way to do things (something that's open to interpretation given the number of string functions that are around). IMHO, the Python 3 vs Python 2 split is a phlisophical rift rather than a technical one. There is no real technical reasons why print and print() cannot coexist.

In all reality, Python 2 and Python 3 are completely differently languages at this point. Communities/companies/projects that have adopted Python 2 do not care about anything that Python 3 gives them. Take for instance Flask - to maintain compatibility with the WSGI spec they have to maintain Python 2 compatibility indefinitely. Less than 30% of all software is compatible with Py3 and any new software releases are built on top of Python 2 - yes I'm looking at Tensorflow.

I'm very doubtful that Python Foundation is going to drop support by 2020. Quite simply - a highly funded Python company (like anaconda) can create a fork.

The only way this situation can be fixed is Python 4 with co-existence of Python 3 and Python 2 functions.

Re: Code that will break in Python 4

#138

> We don't really know yet what Python 4 will look like, but we can be pretty sure that the transition from Python 3 to Python 4 will be a lot smoother Doesn't compute. You can't say you don't know anything about Python4 and immediately follow up with suggestions on how to program for it. And if you really want to be consistent, at least: if (python2): // python 2 else if (python3): // python 3 else: raise "I have no…

It's worse than that. If python 4 is not 100% backwards compatible with python 3, there's no reason to think the problems will be where python 3 is different from python 2. In fact, they will almost certainly be someplace else.

But long before we switch to python 4, we should stop trying to be backwards compatible with python 2.

Re: Code that will break in Python 4

#139
post #24

Earlier quoted context omitted.

Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't overload that constant!

If it was 100% compatible it wouldn't be Python 4, it'd be Python 3.x.x.

There could be other reasons for a version number bump other than the python code being written, like changing the limited ABI. In such a hypothetical version, the python code would be valid, but the stuff linking to the python interpreter wouldn't be.

Re: Code that will break in Python 4

#140
post #24

Earlier quoted context omitted.

Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't overload that constant!

If it was 100% compatible it wouldn't be Python 4, it'd be Python 3.x.x.

Python does not follow Semantic Versioning as far as I know.
Post reply on HN