<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Normally, the builtin modules are the ones that are shipped in Python<br>core. I know you can get a bigger builtins list through freeze, or
<br>through a custom Setup.local, but it is fairly uncommon to do that.<br><br>Also, having extension modules in a namespace is something that I<br>would normally not do. I couldn't tell off-hand whether having<br>extension modules in a package would even work (but apparently,
<br>it does),</blockquote><div><br>Well, it quite doesn't, without the patch ;-) </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
so I would make them global modules just to be safe.<br>Also, they normally have a canonical naming: if they wrap a library<br>called libfoo, the extension module would normally be called<br>foo.so or foomodule.so (on a Unix system;
foo.pyd on Windows).<br>As DLLs don't have hierarchical names, extension modules don't<br>need hierarchical names, either.</blockquote></div><br>Perhaps one example would help to clarify what I mean. I see that there is an
xml.parsers.expat module, with the following content:<br><br>----<br><br>"""Interface to the Expat non-validating XML parser."""<br>__version__ = '$Revision: 17640 $'<br><br>from pyexpat import *
<br><br>----<br><br>Then, there is a pyexpat.c module in Modules, which provides the contents for the aforementioned xml.parsers.expat.<br><br>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?<br><br>Regards,<br>Miguel<br><br>