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

Miguel Lobo mlobol at gmail.com
Mon Mar 12 23:13:57 CET 2007

Normally, the builtin modules are the ones that are shipped in Python core. I know you can get a bigger builtins list through freeze, or through a custom Setup.local, but it is fairly uncommon to do that. Also, having extension modules in a namespace is something that I would normally not do. I couldn't tell off-hand whether having extension modules in a package would even work (but apparently, it does),

Well, it quite doesn't, without the patch ;-)

so I would make them global modules just to be safe.

Also, they normally have a canonical naming: if they wrap a library called libfoo, the extension module would normally be called foo.so or foomodule.so (on a Unix system; foo.pyd on Windows). As DLLs don't have hierarchical names, extension modules don't need hierarchical names, either.

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?

Regards, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070312/9ba3a332/attachment.html

More information about the Python-Dev mailing list