[Python-Dev] Patch 1644818: Allow importing built-in submodules

["Martin v. Löwis"]

Miguel Lobo schrieb:
> Perhaps one example would help to clarify what I mean.  I see that there 
> is an xml.parsers.expat module, with the following content:
> 
> ----
> 
> """Interface to the Expat non-validating XML parser."""
> __version__ = '$Revision: 17640 $'
> 
> from pyexpat import *
> 
> ----
> 
> Then, there is a pyexpat.c module in Modules, which provides the 
> contents for the aforementioned xml.parsers.expat.
> 
> Wouldn't it be simpler and less invasive of the user's namespace if the 
> Python module at xml.parsers.expat was removed, and pyexpat.c declared a 
> module name of "xml.parsers.expat" instead?

It certainly wouldn't be simpler: it would break a lot of existing code,
which all assumes that pyexpat is a module that you can import. Also, it
would noticably complicate the build process, which now suddenly needs
to support submodules.

It wouldn't be less invasive, either: "pyexpat" is a name that is really
unlikely to clash ("expat" itself would already provide that guarantee).

As the former PyXML maintainer, I considered that several times, and
always concluded that it should be not be done.

Does distutils support this kind of setup? Modules/Setup?

IOW, I would expect that there are sooo many places where extension
modules in packages are not supported that it is just a tiny detail
that they don't work in builtin modules (which, as I said, only have
top-level modules, anyway).

Regards,
Martin