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%.
2to3 was _conceived_ of as migration tool, as if evolutionary lineages just all stopped, changed their genome and restarted. Except it only refactored some easy stuff and let the rest fall on the floor.
Six has had way more impact than 2to3. It was only because core Python said running a single 2/3 codebase was UnPythonic that people didn't embrace it sooner. Running a single codebases across both 2 and 3 is now the defacto technique.
Writing in 3 and "compiling down" to 2 gets people writing 3 which is the point, even if they can't run CPython3.
There's nothing to be charitable about, GP's comment is rather clear and stands for itself.
> 2to3 was _conceived_ of as migration tool
And it still is one, so far as I know, which is actually part of the issues with it.
> Except it only refactored some easy stuff and let the rest fall on the floor.
I'm rather well aware of that, which you'd have noted if you'd actually read my comment.
> Six has had way more impact than 2to3. […] Running a single codebases across both 2 and 3 is now the defacto technique.
Sure, but again that has nothing whatsoever to do with the inanity of ranking 2to3 and backwards.
> Writing in 3 and "compiling down" to 2 gets people writing 3 which is the point, even if they can't run CPython3.
You do realise that's complementary to 2to3 right? A big issue of 2to3 is that once you've converted your P2 codebase to pure-3 (not a common subset of 2 and 3) you either have to maintain two different branches making packaging and backporting difficult or you just leave your P2 users out in the cold.
Once again, the purpose of 2to3 is not to regularly run 2to3 to generate a Python3 release from a Python2 source.
I don't think it is nonsensical. There was a tool 3to2 that took Python 3 code and produced Python 2 code. You had to write in a subset of Python 3 but the idea was sound, I think. Python 3 is more strict in ways than 2 and so downgrading the code was easier (e.g. no implicity str/unicode coercions). It looks like 3to2 is not maintained but I liked the idea.
If I were writing a library that needed both 2 and 3 compatibility, I would prefer to write Python 3 code and then run 3to2 on it, rather than going the other way. My own solution is to fork the library, provide only bug fixes for the 2.x version and do all new development in Python 3 only. Porting has taken some effort but not as much as I feared. In retrospect, I'm happy to have invested the time.
It is completely nonsensical in the context it is made in, the purpose of TFA has nothing to do with the purpose of 2to3, it makes no sense to "rank" them.
> There was a tool 3to2 that took Python 3 code and produced Python 2 code. You had to write in a subset of Python 3 but the idea was sound, I think. Python 3 is more strict in ways than 2 and so downgrading the code was easier (e.g. no implicity str/unicode coercions). It looks like 3to2 is not maintained but I liked the idea.
That still has nothing to do with 2to3, whose intended purpose once again is as a helper for a one-shot conversion of an existing Python 2 project to Python 3.
> If I were writing a library that needed both 2 and 3 compatibility, I would prefer to write Python 3 code and then run 3to2 on it, rather than going the other way.
And guess what? If you're starting from a Python 2 project you can use 2to3 to convert it to Python3 then use some other converter to provide P2 releases.
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.
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]...`
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.
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.
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%.