<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&#39;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&#39;t, without the patch ;-)&nbsp;</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&#39;t have hierarchical names, extension modules don&#39;t<br>need hierarchical names, either.</blockquote></div><br>Perhaps one example would help to clarify what I mean.&nbsp; I see that there is an 
xml.parsers.expat module, with the following content:<br><br>----<br><br>&quot;&quot;&quot;Interface to the Expat non-validating XML parser.&quot;&quot;&quot;<br>__version__ = &#39;$Revision: 17640 $&#39;<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&#39;t it be simpler and less invasive of the user&#39;s namespace if the Python module at 
xml.parsers.expat was removed, and pyexpat.c declared a module name of &quot;xml.parsers.expat&quot; instead?<br><br>Regards,<br>Miguel<br><br>