On 2008-05-19 21:26, Brett Cannon wrote:
It is possible to make pickle aware of the module renames, but that doesn't solve problems with other forms of serialization or use of the .__module__ attribute in general.
Why can't we just provide a "from __future__ import renamed_modules" which then provides all the new name to old name mappings in some form (e.g. module proxies or whatever) and leave the existing modules in 2.x untouched ?
I have started a discussion on the stdlib SIG on how to handle this, so I will defer this discussion to there.
Thanks.
But one thing that needs to be decided is if we are ever going to allow ourselves to rename modules without a major version bump, and if so how to deal with this problem. I would hope we don't have to wait another eight years before there is another chance to shift things around if it becomes apparent that some new package should be introduced since 2to3 gives us a very nice way to handle the mechanical aspect of porting code.
We could some kind of module aliasing support to Python. Backporting name changes would then be a matter of loading the right aliasing map into the older Python version. This could probably be done by adding a line if hasattr(sys, 'module_aliases'): modname = sys.module_aliases.get(modname, modname) to the __import__ implementation. By turning .__module__ into a property and applying the same aliasing there, we should be able to resolve most technical issues with a renaming. Alas, too late to change 2.4 and 2.5 :-/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 19 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611