[masklinn]

> 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%.

[sitkack]

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.

[masklinn]

> You are not being charitable.

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.

[nas]

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.

[masklinn]

> I don't think it is nonsensical.

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.