Tim Peters wrote:
The module objects would be different, but that's just about it.
Which was exactly my point. Much code that does *not* use "from ... import ..." in fact relies on having the same module object.
You mean for e.g. hacking the module's globals ?
If you consider a module maintaining pieces of its own state in its own globals as an instance of hacking the module's globals, yes, that's the main problem. For example (there are many, this isn't stretching), if the user ends up with two distinct copies of the tempfile module, its "global" _tempdir_lock becomes two distinct locks, and the truly global mutual exclusion _tempdir_lock was supposed to supply is lost. Ditto for the lock used internally by tempfile's global _counter object. The system-wide uniqueness of some globals is crucial to some modules' correct functioning.
Very true and that's why there is only one module containing the actual code. Globals referenced by the code live in that module. The other module only imports the symbols in the first solution I posted. The second even avoids this extra step -- there's only one module (the packaged one) left in sys.modules which is referenced under two names.
pickles will gladly unpickle using this scheme while a pickle operation automagically starts using the new packaged name.