[Python-Dev] Patch 1644818: Allow importing built-in submodules (original) (raw)

"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).

Regards, Martin

More information about the Python-Dev mailing list