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

Show HN: Python-to-Python compiler for some 3.6 features in older versions

github.com

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#11

Post by castis »

sigjuice wrote: post #8

I am not a Python developer, but thanks for not using the unnecessary term "transpiler".

But isn't that what this is? I was under the impression that a compiler turns source code into machine code whereas a transpiler turns source code into differnet source code?

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#12

Post by wbond »

Ever since mypy started gaining attention, I’ve been looking for a way to write using Python 3 annotations and strip the annotations for release so that the code can run on Python 2.

I never was able to find anyone talking about that goal with mypy, but it looks like this tool may be a solution.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#13

Post by daeken »

castis wrote: post #11
sigjuice wrote: post #8

I am not a Python developer, but thanks for not using the unnecessary term "transpiler".

But isn't that what this is? I was under the impression that a compiler turns source code into machine code whereas a transpiler turns source code into differnet source code?

All compilers turn one form of code into another. Whether that's C to assembly (to machine code), or JavaScript to bytecode to machine code, or Python to Python. Transpiler is just a term referring to a compiler taking one high-level language to another. It's unnecessary because a Coffeescript to JavaScript compiler is a transpiler already; saying "transpiler" there tells you nothing you don't already know.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#14

Post by goatlover »

chatmasta wrote: post #6
sly010 wrote: post #2

Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.

Forward adoption is one thing the JS ecosystem does well (probably due to the sheer necessity of it given the many varying platforms outside control of the developer). Transpiling supersets of the language to the lowest supportable denominator is such an elegant approach. Thanks to projects like babel, typescript, webpack, etc, you can write your code in the most modern language spec, but target platforms not yet sup…

It's a solution to a problem that exists because browsers incrementally support different features of the language, instead of upgrading all at once. That and the older browsers in use when you want to maintain backwards compatibility.

The only reason the Python 2/3 issue exists is because of just enough breaking backwards compatibility in a way that a lot of people didn't agree with in the community. This isn't a thing in Ruby.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#15

Post by jwilk »

antman wrote: post #7
nas wrote: post #3

Interesting but I wonder when you would need a tool like that. I have something related, a fork of Python 3.6 that adds a bunch of backwards compatible behaviour so 2.7 code runs more easily, https://github.com/nascheme/ppython .

Link broken

Remove the trailing ">".

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#16

Post by tyingq »

Great idea.

A writeup on how you handled mapping bytes, bytearrays, unicode, etc, to 2.7 constructs would be interesting.

In code that supports both 2 and 3, I end up with ugly stuff testing sys.hexversion to deal with 3rd party libraries, like pyserial, that expect str in v2, bytearrays in v3.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#18

Post by gizmo385 »

dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

Because sometimes the amount of work required to port a 2.7 project to 3.x isn't worth it.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#19

Post by dec0dedab0de »

skierscott wrote: post #10
sly010 wrote: post #2

Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.

> If python3 adoption is the goal So the goal should be to have codebases in Python 3. > python3 should be the input and not the output How would this accomplish that goal? All the codebases would be in Python 2 then. I bet that removing barriers to run Python 2 code would cause it to stay around longer.

All the code bases are already in 2. This would allow someone to write new internal libraries in 3.6, or migrate existing code one at a time, but still have the project as a whole run on a python2.7 until it is ready.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#20

Post by dbcurtis »

gizmo385 wrote: post #18
dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

Because sometimes the amount of work required to port a 2.7 project to 3.x isn't worth it.

So, then it is a small project that is near end-of-life, and easily replaced?
Post reply on HN