[Python-Dev] Patch 1644818: Allow importing built-in submodules

[Miguel Lobo]

>
> 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