Hacker News new | ask | show | jobs
by naftaliharris 3440 days ago
(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. :-)

2 comments

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.