[Python-Dev] Proposed 3.0 compatiblity module

Guido van Rossum guido at python.org
Fri Jan 12 21:39:59 CET 2007


On 1/12/07, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> ISTM, we can decide to limit 3.0's impact to a single compatibility module,
> essentially as an alternate set of builtins.
>
> import __new_builtins__
> for name in 'bytes dict coerce'.split():      # list any new features you want
> to support
>     setattr(__builtins__, name, getattr(__new_builtins__, name))
>
> The bytes type would just be the new type.
> The dict would have keys=iterkeys, no has_key, etc.
> The coerce function would work but have a DeprecationWarning or somesuch.
> If you want future division, we already have a mechanism for that.
> If you want to eliminate backticks, just grep for them.
> If you don't care about 3.0 compatibilty, just don't import the module.

Most of these make sense, except for dict: dicts are passed around
between modules, and there's little hope that changing the dict type
in *your* module will be able to affect the behavior of dicts you
receive from *other* modules; and the dicts you create and pass out to
other modules will have behavior those other modules don't expect.

> Outside of a compatibility module, we can decide to leave Py2.6 unmolested by
> Py3.0, so I can stop being cranky.

If you're feeling cranky this early in the new year, maybe you should
look for reasons outside this list. :-)

I'm all for striving for minimal impact. I don't think we can attain
zero impact.

BTW, a possible alternative would be to strive for code that runs
under 2.x, and *after automatic transformation using the 2to3 tool*
runs under 3.x, *without mannual patch-up*. That's probably a much
lower bar, and it would still mean that developers wishing to maintain
code that works with both 2.x/3.x only need to maintain a single
version -- the other version could be automatically generated.

Since you need to do a lot of testing anyways to make sure you haven't
accidentally broken compatibility, the effort would be roughly
equivalent to the "identical source" approach that people are
advocating so far, and it would probably lift some restrictions.

For example, working around print becoming a function would mean no
use of print at all when using "identical source"; but that's a
transformation that the 2to3 tool can do trivially and perfectly, so
the "automatic conversion" approach would enable freely using print
statements.

A mixture of the two approaches would perhaps work best.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list