Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

141–150 of 237 posts

Re: Code that will break in Python 4

#141
post #109

The idea of using a runtime conditional to target different major versions of a programming language is hilarious. Really, given the Python 3 embarrassment, I'm not confident in the language as a long-term option.

Nice flame bait. Don't see how it matters whether it is decided at runtime or compile-time. Incompatible versions are a fact of life, and nothing particular of Python.

Re: Code that will break in Python 4

#142

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…

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 Python 2 and Python 3 module, you need to convert them using glue code written in Python 3. Sure it's messy, but writing polyglot code is messier.

Re: Code that will break in Python 4

#143
post #94
post #42

As someone that uses Python intermittently it seems like there's still a lot more tutorials, Q&A, and documentation for v2 on the internet than for v3. When searching for info about python it's often difficult to tell if I'm looking at something for v2 or v3, and when I can tell it's usually for v2.

Usually when it's hard to tell that's because it applies to both. The differences between the two are really not that large.

...which begs the question: why are there any differences at all!

Re: Code that will break in Python 4

#144

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…

Actually C++ is not a superset of C. And it does have these kinds of issues. C++ continued to diverge with C99/C11. https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

Function pointers are one scary area. I don't know if C++11/C++14 decided to fix this yet. Most people relied on undefined behavior to make this work.

Re: Code that will break in Python 4

#145

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 l…

As an aside, this:

> the Python philosophy around one-true-way to do things

I've always thought to be a total joke. There's been like 5 different modules each for string interpolation, subprocess management, and argument parsing. Heck, I thought I was on top of which was in vogue and apparently just two weeks ago there's a new "one true way" to do string interpolation.

Re: Code that will break in Python 4

#146
post #128

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…

Because you actually can write code that is compatible with both Python 2 and 3. Also major issues people have with migration is unicode. In respect of unicode, majority of the code is simply broken and fails to work on Python 3 because Python 3 is more strict about it. In Python 2 you store text and binary data as bytes (no distinction, there is unicode type but it's more hassle to use it and frankly almost no one d…

You can also write code that is compatible with both C and Perl. Doesn't make it a good idea.

Shebang doesn't work on a per-module basis, which is what I am advocating. If there were a way to specify versions at that granularity, there would be no need for 2/3 polyglot tricks.

Re: Code that will break in Python 4

#147
post #5

2020! I wonder if I'll have more luck finding the time to upgrade my python 2 scripts in the next four years than I've had in the last four?

much more likely: you'll finally find the motivation to upgrade your code, not to Python 3 which is 5% better than 2 and 50% more of a pain-in-the-butt, but because there are a multitude of new, faster, parallel-aware languages that are orders of magnitude better, and already make 3.x look like a dinosaur. Move from one dinosaur to a marginally better-but-fussier dinosaur? Doubt it.

Re: Code that will break in Python 4

#148
post #89

Earlier quoted context omitted.

The source to that information (as far as I can tell) is a Reddit post claiming to be from a Microsoft developer. I've worked with programmers dumb enough to write such a version check, so I totally believe this might be true, but I'd love an official source.

This search turns up some quite a few results, including some OpenJDK code: https://searchcode.com/?q=if%28version%2Cstartswith%28%22win... .

that's irrelevant because Microsoft fakes version information for applications by default[1].

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

Re: Code that will break in Python 4

#150
Guido has stated to not compare semver in the past.[0]

Will there be a 3.10 or go to 4.0 after 3.9, per one of his core developers?[1] It's hard to tell with Python's leadership (no intentional mockery of the term leadership).

My guess is that they'll indeed push onwards to Python4 as soon as possible. This being another attempt to make Python2 look as old and crufty as possible. "You're still on Python2? Wow, I'm on 4!". That's the type of political and psychological game the Python core dev team has been playing since 2008 with 3's release. Right alongside the 2020 EOL, another political move. Even though Python 2.7.'10' was never supposed to exist but they went back on that.

This because Python3 is mere technical churn, it is not true technical innovation.

The issue here is really one with the Python core development team. They have also adopted every niche feature into Python3 by whoever came along to ask for it.[2] This was done for the same reasons as the relative rush to rebrand the failed 3.x branch as 4. An attempt to stir up any hype possible for 3.0+.

They got so much wrong with Python3. Feature soup, unicode, and performance losses over 2. Unicode-by-default is the big deal and they didn't even get that right. They simply remapped unicode to str. Which for such a big breaking change, should've been UTF8 alongside other new languages such as Go.[3] But it's worse than that, Python3's feature soup continues in 3.6 there will likely be a 4th string formatting option[4] among throwing everything they can against the wall to see what sticks (while bloating the supposedly simple, "beginners" language).

While Python2 has been riding high in popularity[5], it has absolutely nothing to do with Python3. It's in spite of it.

There's good reason the core dev team "extended support" for 2.7. It's because they really did create a new, much less successful language and would've lost complete control of Python had they not done it.

Python3 is a language that looks mostly like Python, but is Python in name-only. Worse of all, it doesn't stand on it's own two feet with technical merits. I would personally recommend sticking with 2 until 3 ever makes sense, or finding something else to use like Swift or Go.

Unlike a web browser or another piece of software, the "latest version" of a programming language is not always in the end-user's best interests.

[0]https://twitter.com/gvanrossum/status/583346987925278720

[1]http://www.curiousefficiency.org/posts/2014/08/python-4000.h...

[2]http://learning-python.com/books/python-changes-2014-plus.ht...

[3]http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

[4]https://www.python.org/dev/peps/pep-0498/

[5]http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

Post reply on HN