[stdlib-sig] Changing the 2.6 renames to not break pickle

Raymond Hettinger python at rcn.com
Tue May 20 02:10:05 CEST 2008


From: "Brett Cannon" <brett at python.org>
> So, here is my idea (only need to care about modules that have stuff
> to pickle, e.g., don't need to change test.support):
> 
> * Rename lib-old to lib-new
> 
> * Change the names in lib-new to the new names.
> 
> * Change the names in the stdlib to the old names.
> 
> * Move the Py3K warnings out of the stubs in lib-new and put them in
> the modules directly stored in the stdlib.
> 
> * Change the imports in the stubs in lib-new to import the old name
> and suppress the Py3K warning (probably use
> test.support.catch_warning() with a *very* specific ignore filter).

That plan seems harmless enough, but why bother?


> I think that gets __module__ set to the old module name even when code
> is imported with the new name. It should also allow the Py3K warnings
> to stick around without causing issues when importing from the new
> name or suppressing other Py3K warnings. What do people think?

What is the purpose of 2.6 knowing anything about the 3.0 module names?
Since this is the kind of thing that the 2-to-3 converter handles easily,
how does this make my life any easier when porting programs to 3.0?
AFAICT, there is no benefit to me as a programmer, so why bother?


Raymond


More information about the stdlib-sig mailing list