For the past few years, I've been focused mostly on doing my own things, and not really following what was happening in the "core" Python community. Reading this post today by Brett Cannon about the "consensus" that has apparently emerged by the language summit at PyCon 2014 about writing code compatible for both Python 2 and 3, I was reminded about the release of version 1.0 of Crunchy
Crunchy 1.0 is compatible with Python 2.4, 2.5, 2.6 ... and 3.1. It is also compatible with Jython 2.5 modulo some bugs when trying to work with examples containing unicode strings.
That was in 2009. At 2.1 MB (zipped), Crunchy was not exactly a small script...
Why has it taken so long for this to become the norm?....
Due to a lack of interest in Crunchy, I have essentially not developed it much further past that point, and it is almost certainly not compatible with newer versions of Python...
It's one of the places where the Python-dev isn't aligned with rest of the world. The new "consensus" is internal. I agree with you; I'm one of many who suggest that people write in the source-compatible subset of Python 2/3.
ReplyDeleteFor example, Lennart Regebro at http://python3porting.com/noconv.html writes "Although the official documentation for Python 3 discourages writing code for both Python 2 and Python 3, in some cases it is desirable."
Cannon, in the 3.2 release's "pyporting" (see https://docs.python.org/3.2/howto/pyporting.html ) suggests three alternatives, (3to2, source compatible, or 2to3) but there is no clear suggestion for which one, though a slight preference for using 3to2. The source compatible option is described as "counter-intuitive".
The 3.2 pyporting also says that the choice of approach is "will be a per-project decision", while the new version is much more direct: "both Python 2 & 3 simultaneously", without listing the built-time 2to3 or 3to2 options.
The projects that I know of which did the transition use 2/3 compatible code, often with the help of six or similar tools.