[Python-3000] Code working in both 2.x and 3.X

[Jim Jewett]

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