Code that will break in Python 4 • Hacker News Board

Re: Code that will break in Python 4

#161

Post by semi-extrinsic » Tue, Jan 12, 2016, 8:04 PM UTC

takeda wrote: post #128

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…

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…

The problem with shebangs used to be (don't know if it still is) that quite a few OS's had python 2.X, but no actual binary called `python2`, just `python`.

Re: Code that will break in Python 4

#162

Post by verbatim » Tue, Jan 12, 2016, 8:04 PM UTC

artursapek wrote: post #26

Holy shit - people actually write code like this?

Yes. Lots of people. You basically have to if you want to support both Python2 and Python3. (And in some spaces, you really do want to support both.)

Re: Code that will break in Python 4

#163

Post by verbatim » Tue, Jan 12, 2016, 8:12 PM UTC

Grue3 wrote: post #156

orf wrote: 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.

Please elaborate. Which feature of Python 3 would be impossible to implement in Python 2? Note that Python 3 code is not guaranteed to work in Python 4, but you are guaranteed to (relatively) painlessly port it, since all Python 3 features are implemented in Python 4 in some way.

Pick a Python 3 feature and let us know how you would implement it in Python 2.

Re: Code that will break in Python 4

#164

Post by mioelnir » Tue, Jan 12, 2016, 8:13 PM UTC

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.

Re: Code that will break in Python 4

#165

Post by marcosdumay » Tue, Jan 12, 2016, 8:14 PM UTC

colanderman wrote: post #145

sandGorgon wrote: post #136

Earlier quoted context omitted.

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.

I always thought that was mocking with Perl, and nothing else.

Re: Code that will break in Python 4

#166

Post by vegabook » Tue, Jan 12, 2016, 8:17 PM UTC

Latty wrote: post #157

vegabook wrote: post #143

Earlier quoted context omitted.

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

Because the differences were important and central to the language.

Only central to the pedants who wanted to "clean it up", and not central to the user base which, as anybody can see, is now cleaved into two warring factions, a result which is far worse than any of the marginal "improvements" can compensate for.

Re: Code that will break in Python 4

#167

Post by takeda » Tue, Jan 12, 2016, 8:18 PM UTC

colanderman wrote: post #146

takeda wrote: post #128

Earlier quoted context omitted.

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.

That's a strawman argument. Majority of python libraries are written that way.

I guess I'm incredibly lucky or you're incredibly unlucky, because I did not run into a library that would only run on Python 2. Ok, I did run into some, but those were no longer maintained and frankly I would not use them even on Python 2.

Re: Code that will break in Python 4

#168

Post by takeda » Tue, Jan 12, 2016, 8:21 PM UTC

semi-extrinsic wrote: post #161

takeda wrote: post #128

Earlier quoted context omitted.

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…

The problem with shebangs used to be (don't know if it still is) that quite a few OS's had python 2.X, but no actual binary called `python2`, just `python`.

Python installs itself as pythonX.Y (for example python2.7) then symlinks such as python2 (pointing to python2.7) and python (pointing to python2) are made.

Re: Code that will break in Python 4

#169

Post by takeda » Tue, Jan 12, 2016, 8:29 PM UTC

sandGorgon wrote: post #136

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…

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…

> yes I'm looking at Tensorflow.

Check the very first issue that was reported: https://github.com/tensorflow/tensorflow/issues/1

Re: Code that will break in Python 4

#170

Post by CamperBob2 » Tue, Jan 12, 2016, 8:31 PM UTC

pearjuice wrote: post #117

To be honest, I am quite surprised that even in Python 4 whitespace is still an integral part of the syntax.

Too many egos at stake, at this point. Whitespace will always be syntactic in Python because nobody with any influence wants to admit it's a mistake.