Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

Post reply on HN
Print view View original

191–200 of 237 posts

Re: Code that will break in Python 4

#191

Post by Nrpf »

BuckRogers wrote: post #184
douchescript wrote: post #172

Earlier quoted context omitted.

Amen! Ruby managed the transition to unicode much better as they delivered 2x performance increase at the same time AND labeled the new version 1.9 instead of two. Much the same problem. Yes python 2 is OK but it's legacy mode and people will move on. I think one of the selling points of python vs ruby is that its so often OK to just use system python(2) versus ruby where you really need to use something like rbenv.…

No breaking change was required for that. :) The PyPy guys have removed the GIL with existing Python2 code.[0] The CPython core dev team doesn't want to work that hard though- they've just created a lot of needless work for others with their decisions. You're right though, unless someone takes on the mantle of CPython2, we're looking at being forced to move to 3 or find something else. I personally think '16/'17 will…

Julia

Re: Code that will break in Python 4

#192

Post by unfamiliar »

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've always wondered this. Why not have .py and .py3 extensions, and require the python 3 interpreter to fall back to Python 2? That would also solve the problem of "which version of Python is this script I found written in?"

Re: Code that will break in Python 4

#193

Post by semi-extrinsic »

takeda wrote: post #168
semi-extrinsic wrote: post #161

Earlier quoted context omitted.

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.

It's mentioned in PEP0394 that some older distros did not have python2 even though python 2.X was installed. Since RedHat still supports a release with Python 2.4 as the default, I guess it might still crop up on some boxen, at least for another year until RHEL 5 reaches end-of-life.

Assuming python points to python2 will also break stuff, though, there are more bleeding-edge OS's where python points to python3 and has done so for years (e.g. ArchLinux).

Re: Code that will break in Python 4

#194

Post by comex »

hyperpape wrote: post #189
colanderman wrote: post #142

Earlier quoted context omitted.

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…

I wonder if there's even a reasonable way to do this in Python. In C, strings are data that you're explicitly passing around, but in Python, you are constantly calling __getattribute__ under the hood just to execute your code. I don't know that it would be impossible to make that all work, but I wouldn't assume that it is.

You don't need to actually convert anything: Python 2's str can be identified with Python 3's bytes, and unicode with str. You 'just' need to have their __getattribute__ methods, along with a ton of standard library functions, check the Python version of the caller and change behavior accordingly. Ugly, but I think it would mostly 'just work' for user code.

Re: Code that will break in Python 4

#195

Post by orf »

Grue3 wrote: post #185
verbatim wrote: post #163

Earlier quoted context omitted.

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

Easy. Feature: print function. Implementation: from __future__ import print_function Yes, that magical, backwards-incompatible, print function has been in Python 2 all along! Feature: unicode strings Implementation: from __future__ import unicode_literals Amazing! The magical, backwards-incompatible unicode strings backported to Python 2 with one single line. I could go on and on.

> Amazing! The magical, backwards-incompatible unicode strings backported to Python 2 with one single line.

Except it's not even slightly close to that is it. unicode_literals is something completely different.

How about removing old style classes? Is `class x:` old style or new style in Python 2, in this imaginary interpreter of yours? How about the default object comparison being sane in Python 3. How about the changes to builtins returning iterables over lists? How about the import system being more sane? How about removing backticks? How about actually handling the unicode differences?

I could go on and on, and I hope your answer is not 'well we just need more __future__ imports don't we'.

Re: Code that will break in Python 4

#196

Post by berntb »

takeda wrote: post #167
colanderman wrote: post #146

Earlier quoted context omitted.

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.

So the problems with upgrading from Python 2 to 3 because of library support are over? Including linked C code?

Or is that just your lucky experience?

Re: Code that will break in Python 4

#199

Post by orf »

BuckRogers wrote: post #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…

Damn, I upvoted you way too early.

> They have also adopted every niche feature into Python3 by whoever came along to ask for it.

You link to async/await as an example? You realize that's a huge deal and is an awesome feature right? It was something sorely missing, but replicated well with generators (thanks to Python being awesome) since Twisted and Python 2.4. Now is exactly the time to ratify it into the language. His complaints about concurrent programming are senseless as async/await are single threaded and avoid most of the concurrency issues you would typically run into when using threads. They also look a hell of a lot nicer and explicit than 'yield from x'.

That whole link[1] is garbage, I don't have enough space to comment on the many absurd statements it contains, but FYI the scientific community in Python is huge and they have been begging for a matrix operator.

You sound like you have a large Python 2 codebase that you don't have the time or resources to upgrade. That sucks. Don't channel that hate into Python 3 though. Start your new projects in it and have a play, you will like it.

1. http://learning-python.com/books/python-changes-2014-plus.ht...

Edit: That link is like reading the republican far-right news about how Obama is a Muslim sleeper agent. One of his complaints is that "The docs are broken on Windows and incomplete" when he's viewing them using an IE6 frame inside a Windows help file - it even tells him his browser is 'ancient', and he still complains some non-important JS is broken? Oh god. Or how getting rid of .pyo files is a terrible thing, or how type annotations will eventually destroy all that is holy about dynamic typing....

Re: Code that will break in Python 4

#200

Post by colanderman »

marcosdumay wrote: post #165
colanderman wrote: post #145

Earlier quoted context omitted.

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.

Then my analysis that it is a total joke is correct ;)
Post reply on HN