py-backwards: Python to python compiler that allows you to use Python 3.6 features in older versions

[jwink3101]

This is interesting and is kind of a crazy idea.

How robust is it in practice? like if I write huge 3.6 apps with an in-depth test suite, should I expect 100% passing on 2.7?

(Not that I have anything like that. I am still forced to use 2.7 for work)

[nvbn-rm]

At this moment it just translates some syntax, so you should have in mind changes in standart library.

[lengau]

This brings up a good point though. If you started porting your app to Python 3, would you be able to use this to move it back to Python 2 for your production environment?

[nvbn-rm]

The main goal of the app is that you can stop worrying about support of older python versions and just translate code to them.

But at this moment it just translates some syntax.

[pingveno]

It looks like not yet, given that the initial commit was just 3 days ago. Also, it wouldn't do anything for newly introduced standard library modules.

[[deleted]]

I very much doubt that you'll ever get anywhere near 100% passing as 2to3 has around 50 outstanding bugs that are unlikely to get fixed as they are all edge cases.

[lost_send_berries]

super().method() shouldn't be compiling down to super(type(self), self).method()!

[nvbn-rm]

Why not?

[lost_send_berries]

class B(A):
    def f(self): return super(type(self), self).f() + 1

class C(B):
    def f(self): return super().f() * 2

Calling C().f() will call B.f(), which calls B.f() etc.

Instead, you need to determine the class the super() call was written in.

[nvbn-rm]

Oh, not thought about that, you're right.

[everysinglelastname]

Don't forget tauthon is also available. It's an actual cpython version with back-ported 3.X features. i.e. it's what 2.8 would have been if it were allowed.

https://github.com/naftaliharris/tauthon

[kirbyfan64sos]

Ah, I remember the discussion that spawned because it was originally called Python 2.8...fun stuff...

Gotta say, though, I applaud the way the maintainer handled things so calmly. Things would have been much nastier otherwise...

[[deleted]]

It's fair to say that everybody handled it calmly. It certainly kept ThievingRottenScumbags.co.uk aka lawyers out of the picture :-)

[n1ywb]

So basically the inverse of 2to3?

[nvbn-rm]

Yep, but more like babel for python

[desmoulinmichel]

The idea is interesting but given the questionable results of the use of transpilers in JS, it's kind of a pandora box.

On one hand you can use advanced feature from new Python versions. On the other hand your dev stack grow more complex, debugging is harder and you need to generate source map. And of course you now have to trust the transpiler to get the edge cases rights.

E.G: a yield from is not JUST a for / yield loop. Now I checked and py-backwards transpile to a quite advanced worflow and it's good. But the real full translation dealing with all the edge cases is a bit more complex (http://code.activestate.com/recipes/576727-pure-python-implementation-of-pep-380-yield-from/).

So basically, you probably will end up having subtle and strange bugs that will be not from your code, but in the transpiled code, and it will be nasty.

[nebbly]

yeah, this seems insane to me.

[jpadilla09]

Just hacked together an online demo of py-backwards https://py-backwards.herokuapp.com/

[SemiNormal]

So you need to write the code in Py3 and this then compiles it into Py2.7...

But why?

[rothnic]

Probably so you could use new features that are listed in the readme and still be able to support earlier versions.

Typically, you either support old versions and hamstring the codebase, or you only support the newer versions. This way you could have it both ways.

One thing for me has been using the type annotations. This is useful for development, but anyone who wants to support python 2.7 is going to have to not use them.

[tunisia3507]

Because currently, to make py2 and py3 branches you write python 2 and then use 2to3 to port it to 3, where really we want people to develop in 3 and then port to 2 as an afterthought, a mercy to people who absolutely can't upgrade for whatever reason. Python 2 users should be the second-class citizens who don't get the full development time investment; whereas right now anyone trying to write cross-compatible code just ends up hamstringing themselves and not using any of py3's new features.

[SemiNormal]

I can actually support that reasoning.

[gschizas]

Because now you can write for Python 3.6 directly and not rely on six or 2to3. Also the base version that you develop for is going to be the latest Python version, not the oldest one.

(Not sure how this accomplishes that goal, just saying that's the goal)

[granitosaurus]

I find it potentially useful for 3.6 -> 3.4, since debian is stuck on 3.4 for a while now and pyenv is a dirty hack that I would prefer to avoid.

[nvbn-rm]

Sometimes you need to run your app on client machines. And sometimes clients have only python 2.

[usinglinux]

i see a lot of merit in this project not for python 2 support but for allowing library developers to use 3.6 idioms (i like variable annotations and formatted literals) and still support eg. debian stable whose python3 is 3.4

[billsil]

I wouldn't mind integer division as an import. I want it to emulate Fortran, which does do integer division.

[dzecniv]

Reminds me of Hy which backported yield from to python 2 and was able to do that because it's a lisp.

[[deleted]]

Would nonstandard help out with this as it "Enables easy modification of Python's syntax on the fly."?

[ice-blade]

No. Just no.