Code that will break in Python 4 • Hacker News Board

Re: Code that will break in Python 4

#121

Post by ergothus » Tue, Jan 12, 2016, 6:39 PM UTC

OrangeTux wrote: post #41

I don't get it. When Py4 comes in sight they'll fix it probably so `six.PY3` is only True when using a Python3 interpreter and I guess they'll introduce a viariable `six.PY4`.

That's the point...if the code says "If Py3, do (modern code) else do (old code)", then when/if py4 comes out, and six.PY3 is False, you end up running (old code).

Obviously you don't know if (modern code) is Py4 compatible, since we don't know what py4 is, but while the py3 code MIGHT be runnable under py4, the py2 code is ALMOST CERTAINLY not going to run under py4.

So instead, make the check for PY2 code:

If Py2 do (old code), else do (modern code).

That MIGHT break under Py4, if modern code isn't future code, but also MIGHT work, whereas the other version WOULD break under Py4.

Same story if you're using sys.version[] rather than six.

Re: Code that will break in Python 4

#122

Post by orf » Tue, Jan 12, 2016, 6:41 PM UTC

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…

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

Because that would make the interpreter a whole lot more complicated. A lot of technical debt was cleared with the 2-3 transition, adding it back in defeats the point.

C/C++ is different, C++ is a superset of C. That makes things a lot easier.

Edit: Ok, C++ is not a superset, common misconception.

Re: Code that will break in Python 4

#123

Post by xrstf » Tue, Jan 12, 2016, 6:43 PM UTC

kedean wrote: post #111

mark-r wrote: post #33

Earlier quoted context omitted.

Yes, they should make the constant True for both Python 3 and Python 4. If you need to make a finer distinction, use a different package.

Then what was the point of using the PY3 constant?

Maybe readability? "if six.PY3" is easier on the eyes than "if not six.PY2". At least to me. ;)

Re: Code that will break in Python 4

#124

Post by SixSigma » Tue, Jan 12, 2016, 6:43 PM UTC

write your own vtable

    goto = {2:fn2, 3:fn3}
    if six.PY in goto :
        goto[six.PY]()
    else :
        sys.stderr.write("ack, no python to run!\n")
        sys.exit()

Re: Code that will break in Python 4

#125

Post by collinmanderson » Tue, Jan 12, 2016, 6:46 PM UTC

bhaak wrote: 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…

Currently the issue is wontfix'd: https://bitbucket.org/gutworth/six/issues/22/variable-sixpy3...

I personally doubt the author's statement: "six will be long dead and forgotten by the time Python 4 rolls around."

Re: Code that will break in Python 4

#126

Post by warp » Tue, Jan 12, 2016, 6:46 PM UTC

sanderjd wrote: post #120

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

https://searchcode.com/?q=if%28version%2Cstartswith%28%22win...

Re: Code that will break in Python 4

#127

Post by m3koval » Tue, Jan 12, 2016, 6:47 PM UTC

orf wrote: post #122

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…

> require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code Because that would make the interpreter a whole lot more complicated. A lot of technical debt was cleared with the 2-3 transition, adding it back in defeats the point. C/C++ is different, C++ is a superset of C. That makes things a lot easier. Edit: Ok, C++ is not a superset, common misconception.

C++ is not technically a superset of C. Here are a few examples that are valid in C, but not C++:

http://stackoverflow.com/a/1201840/111426

However, it's close enough that I generally agree with your point.

Re: Code that will break in Python 4

#128

Post by takeda » Tue, Jan 12, 2016, 6:47 PM UTC

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 does use it) while in Python 3 text and binary data are two distinct types.

So if you have code in Python 2 and you did not distinguish what is text and what is binary now you have to go through your entire code and identify all those parts, this is especially hard since Python is dynamically typed language and you don't have type checker to help you with that.

This is also why it is much easier to write Python 3 code and make it run on Python 2 as well than the other way around.

As for having interpreter compatibility layer. First python does not care about extension you use, and unlike some languages it actually allows you to install multiple versions at the same time without conflicts (checked 2.4 all the way to 3.5). You can easily control which version you want to use by shabang, for example:

    #! /usr/bin/env python2

    #! /usr/bin/env python3

    #! /usr/bin/env python3.5

Re: Code that will break in Python 4

#129

Post by hellofunk » Tue, Jan 12, 2016, 6:47 PM UTC

orf wrote: post #122

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…

> require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code Because that would make the interpreter a whole lot more complicated. A lot of technical debt was cleared with the 2-3 transition, adding it back in defeats the point. C/C++ is different, C++ is a superset of C. That makes things a lot easier. Edit: Ok, C++ is not a superset, common misconception.

>C/C++ is different, C++ is a superset of C. That makes things a lot easier.

This is entirely incorrect, but I'll give you a break since it is a common misconception. C and C++ are truly two different languages. C is not 100% compatible with C++.

Re: Code that will break in Python 4

#130

Post by thaumasiotes » Tue, Jan 12, 2016, 6:48 PM UTC

orf wrote: post #122

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…

> require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code Because that would make the interpreter a whole lot more complicated. A lot of technical debt was cleared with the 2-3 transition, adding it back in defeats the point. C/C++ is different, C++ is a superset of C. That makes things a lot easier. Edit: Ok, C++ is not a superset, common misconception.

> C++ is a superset of C

No it isn't.