|
|
|
|
|
|
by sitkack
3347 days ago
|
|
|
You are not being charitable. 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.