(original) (raw)
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