3 ms·
I thought 2to3 was designed for converting apps from 2 to 3, rather than making them polyglot? I think six could have simplified things here, however.
by alexchamberlain 9y ago
I thought 2to3 was designed for converting apps from 2 to 3, rather than making them polyglot? I think six could have simplified things here, however.
- keenerd 9y agoYou can't make something truly polyglot across all of 2.X and all of 3.X. However much of py3 syntax is supported by py2. As far as I know, 2to3 doesn't produce py3-only syntax. I diff the original and the converted code, merging the non-compatible parts into a version check.
- masklinn 9y ago> You can't make something truly polyglot across all of 2.X and all of 3.X. There's little reason to though, generally you want 2.7 and >=3.x (the simplest is 3.5, 3.4 is fairly easy, 3.3 is possible but starts being more annoying) > As far as I know, 2to3 doesn't produce py3-only syntax. It does: print function, metaclass kwarg. It will also generate syntactically valid but P2-incompatible code (with_traceback calls) as well as possibly semantically break P2 code (rename __nonzero__ to __bool__, basestring and unicode to str, stdlib changes, raw_input to input, …)
- keenerd 9y agoPrint() is valid in Python2. It will print a tuple under some conditions, but that is still syntactically valid and a graceful degradation. (Print is for humans to read. As long as a human can understand it, good enough. Going for full identical behavior costs extra :-) Valid-but-incompatible is fine for polyglot stuff. Merge the files and put in a version test around those parts.
- masklinn 9y ago> Print() is valid in Python2. print("a", end=" ") is not, neither is class Foo(metaclass=Bar)
- deleted 9y ago[deleted]