[Python-Dev] Patch 1644818: Allow importing built-in submodules
"Martin v. Löwis"
martin at v.loewis.de
Mon Mar 12 23:50:17 CET 2007
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).
More information about the Python-Dev