[Python-3000] stdlib reorganization

[Josiah Carlson]

Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> > There was also a proposal that I was supposed to work on getting
> > formalized somewhat over a year ago about getting __main__ relative
> > imports to have __main__.XXX names, which would further reduce (if not
> > remove entirely) name collisions in sys.modules, but I got caught  
> > up in
> > my attempt at a relative import hook.
> 
> That would really suck.

Here's a better description of what I was trying to get across, which
likely sucks quite a bit less than what I think you were thinking I
meant.

Every import in the module known as __main__ functions exactly the same
as it did before.  That is...

    import my_library
    from my_package import other_library

All continue to work.  However, the proposal I was working on (which was
suggested by Guido) was that the __name__ given to those modules and
packages would be relative to __main__, that is, you would get
'__main__.my_library', '__main__.my_package', and
'__main__.my_package.other_library' as __name__ attributes of those
modules and packages, and those same names would be used in sys.modules.

The purpose of this was that so sys.modules could do the right thing,
vis-a-vis module import caching and accidental system import shadowing.
Like, say for example, I have an 'email' module that I have written, but
I discover later that I want to access the standard library 'email'
package, I can't right now because even if my 'email' isn't in the
current module's path search, it will give me my 'email' because it is
in the sys.modules cache.

However, if all modules which are imported relative to __main__ got a
__main__ prefix in their name, my email module would presumably get a
name of '__main__.email', and I could still import the stdlib email
package, becayse sys.modules would have a '__main__.email' and not a
'MYTHICAL_STDLIB_PREFIX.email'


One of the reasons for relegating the standard library to a 'py', or
site packages to a 'site' is that one would ultimately reduce name
collisions, and one could be explicit about where they expect their
modules and packages to come from: the standard library, user-installed
site-packages, etc.


Whether or not to include the just-mentioned MYTHICAL_STDLIB_PREFIX in
all system/package imports is somewhat different, but also related to,
whether or not to create a higher-level py or site package.  I can
understand the _undesireability_ of having those higher-level packages,
but perhaps you can understand the _desireability_ of having names
include a prefix which defines where the modules/packages came from,
specifically to reduce and/or remove __name__ collisions with user code.


 - Josiah