Hacker News Reader

Comment by didibus | Hacker News Reader

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3?

I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish.

Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name.

I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.

View on HN

(I'm the primary author of this interpreter).

> Backporting features will be hard

It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60

> Why try to create an inferior python 3?

The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)

The ultimate goal is to build an interpreter that can run both Python 2 and 3 code.

That is a great goal, I fully support you.

so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there

Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.

Thanks for working on this. I like some of the stuff in Python 3, but I don't see any compelling reason to switch to it; I'd much rather see the vast majority of features in 3 moved back to a 2 series interpreter. That most of the features can be moved back is, in itself, an important statement on whether 3 was necessary at all.

I agree. What exactly is the point of backporting features, when the main reason people give for wanting to use Python 2 is for legacy applications? What 8-year-old codebase is going to be updated to use `async`? And if you're starting a new project, why not write it in Python 3, which has first-party support?

>And if you're starting a new project, why not write it in Python 3, which has first-party support?

Because you're importing big legacy python2 libraries.

> Giving people more time to transition is going to benefit some projects.

Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10.

Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.

I disagree. When your dev team is totally busy working on features that customers are actually paying for, there is less than no business case for porting to Py3.

In 2017 you may be right.

In 2020? There will certainly be a business case once you get hit with an RCE in 2.7 because there will be no new security patches.

> Why try to create an inferior python 3?

I think the point is -- it will not be an inferior python 3.

It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes.

That will make it a superior python 3.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes) use "".

> what is usually needed in algorithms

Depends what you're working with, obviously.

If you think py2 is the sane one, then you must work on a project where everything is written and communicated in bone standard roman characters.

For the vast majority of the actual planet, this simply isn't the case.

So you admit that byte strings and Unicode strings are different data types, yet you claim that Python 2 is the sane one for choosing to both using exactly the same class?

The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x

Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.)

PS. https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.

Yes I was thinking about twisted

Sure there are some, but several lists (for example, http://py3readiness.org) show that over 95% of very popular packages support Python 3, and some only support Python 3. At this point while you might need 2 for some very specific purposes, 3 has the majority of important packages and new development.

I stand corrected. I realize that it was 4 years ago, since I tried to learn Python ... And at that point in time key libraries, which I for instance read books to learn, twisted, was 2.7 only ...

As I mentioned elsewhere, my go-to example was PCSC-Lite support. I thought it so old and obscure it will never happen. But look, https://pypi.python.org/pypi/pyscard/1.9.4

Reply on news.ycombinator.com