Code working in both 2.x and 3.X
Raymond Hettinger wrote:
Also, I'm wondering if the desire for 2.6 warnings is based on the notion that it will be possible to get large tools to work under both Py2.x and Py3.x.
I had certainly assumed it would be possible. In fact, I had assumed that the 2->3 translator would have a mode which left the code running in both. This might not be the cleanest possible code for either line (parens in 2.x, some extra iter calls or missed shortcuts, etc), but it should certainly exist. If it doesn't, then people who do want to support both lines will themselves have to work exclusively in 2.x and "compile" to 3.x.
With all the module renaming/packaging,
I had believed that 2.x would support both names, typically as >>> # make an deprecation warning, or log entry >>> from oldname import * So code using the new names may not work in 2.5, but should work in 2.6. If you want it to work in 2.3, you either use conditional imports or include your own forwarding modules for older pythons.
old-style classes disappearing,
This is only a problem if you rely on specfically old-style semantics. Most old-style classes that I see work fine as new-style; the author just didn't want to put in the extra boilerplate (or wanted 1.5 compatibility, or just didn't bother to make a change).
encoded text objects,
This one I'm less sure about, but it seems that programs which work correctly with both str and unicode in 2.x should work with 3, and that programs which (in practice) restrict themselves to ASCII will continue to work.
real division
You can already get this a __future__ import, and you can explicitly request the old form (in both lines) by truncating the result.
and whatnot; that notion may be a pipe-dream.
I hope not. That said, I'm not so sure about C extension modules... -jJ
participants (1)
-
Jim Jewett