I think you could get a long way with minor changes along the lines of making site-packages a package itself.
This wouldn't work since in that case you'd have the problem of having to fix class names in e.g. pickles for objects which you don't know anything about. We do know about objects in the Python standard lib, so we could take care to have mechanisms like pickle deal with them properly.
IOW you're suggesting we do a near-infinite amount of work to the core just so that others can be sloppy in their choice of names for their modules. Bah.
I believe that the more Python grows (not only the core, but the complete set of available modules and packages in the Python universe), the less likely we are going to hit a problem.
I would say, OK, so it will go away by itself, but I guess you made a typo there, and really meant "the more likely...". :-)
But making the core go away doesn't reduce the problem enough: the more likely problem is two 3rd parties unaware of each other each picking the same name.
I'm rejecting the proposal of a single top-level package named "python".
You've written that before, but you still haven't given any explanation of why a single package would be worse than a multi-level hierarchy of modules (e.g. grouped by application space).
Because a single package doesn't have any other benefits besides getting out of the way from 3rd party developers.
At least a proper hierarchy would have the other benefits of grouping. (But better make it a shallow hierarchy! remember "Flat is better than nested.")
I think that simply moving to one package would cause less breakage and make the whole transition process much easier than having to tweak code into using some complicated multi-package structure.
Given that you now want us to add special counter-measure to pickle, I doubt that very much.
FWIW, I've been through all this with the mx packages and using a single new package caused the least amount of work. Even better: it turned out to be easy to provide backwards compatibility code so that applications still using the old layout continue to run, but start using the new structure in their pickles.
So it's no big deal for 3rd party developers to do what they should do to deal with this problem. Good to hear. Given that when we change the standard library, *every* Python user (and developer) is affected, I prefer the status quo.
No need to get heated, though. I just thought that it would be a good time to start thinking about this option again.
And this would be a good time to end this thread. :-)
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)