Show HN: Python-to-Python compiler for some 3.6 features in older versions
1–10 of 113 posts
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#2Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#3Interesting 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 .
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#4Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.
That's why 3to2 is a thing.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#5Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.
> Imho this is a much better solution than 2to3.
That's nonsensical since it solves a completely unrelated problem.
2to3 was conceived of as a one-shot migration tool for Python 2 codebases. Not as a way to build cross-version Python, and not as something to use repeatedly (which it why it is relatively simplistic and fallible), just as a way to take an existing codebase and handle the first 90% of migrating to Python 3, leaving you with the second 90%.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#6Imho 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 supporting it.
I suspect this may be easier to achieve with JS than other languages because its prototypical nature makes it easy to compose dependencies. However, there is certainly a lot that other communities can learn from the JS community's solutions to this problem.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#7Interesting 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
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#8I am not a Python developer, but thanks for not using the unnecessary term "transpiler".
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#9Imho 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…
> is such an elegant approach
In theory more than practice. For example if you use array destructuring (`[x, y] = something`) and Babel cannot verify that `something` is always an array it inserts a 664 character function that handles generators and other things. That adds performance and size overhead (grep for _slicedToArray in your compiled js files), when all you really want is `x = something[0]...`
https://babeljs.io/repl/#?babili=false&evaluate=true&lineWra...
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#10Imho 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.