[Python-Dev] Module renaming and pickle mechanisms

[Guido van Rossum]

On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <python at rcn.com> wrote:
>> Nick writes:
>>>
>>> M.-A. Lemburg wrote:
>>> > I don't think that an administrative problem such as forward-
>>> > porting patches to 3.x warrants breakage in the 2.x branch.
>>> >
>>> > After all, the renaming was approached for Python 3.0 and not
>>> > 2.6 *because* it introduces major breakage.
>>> >
>>> > AFAIR, the discussion on the stdlib-sig also didn't include the
>>> > plan to backport such changes to 2.6. Otherwise, we would have
>>> > hashed them out there.
>>>
>>> I think MAL is 100% correct here (and I expect Raymond will chime in to
>>> support him at some point as well).
>>
>> And until then, a +1 for MAL's position from me as well.  2.x should be
>> quite conservative about such changes...
>
> I concur.

And a "me too" post about being conservative by default as well.

I'm not sure how effective a "from __future__ import renamed_modules"
would be, since such future imports are meant to affect the semantics
of the *current* module only, whereas which name to use when pickling
a module reference is most likely a global choice. So perhaps some
other way to changing the default behavior globally would be more
appropriate. Assuming it's really the pickle module that needs to know
about this, how about making this a per-Pickler-instance flag? if you
wanted to write 3.0 compatible pickles you'd have to do something like

p = pikle.Pickler()
p.use_new_module_names(True)
pkl = p.dump(<object>)

We could supply an extra flag to the dump() and dumps() convenience
functions as well.

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