Miguel Lobo schrieb:
> 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?
It certainly wouldn't be simpler: it would break a lot of existing code,
which all assumes that pyexpat is a module that you can import. Also, it
would noticably complicate the build process, which now suddenly needs
to support submodules.
It wouldn't be less invasive, either: "pyexpat" is a name that is really
unlikely to clash ("expat" itself would already provide that guarantee).
As the former PyXML maintainer, I considered that several times, and
always concluded that it should be not be done.
Does distutils support this kind of setup? Modules/Setup?
IOW, I would expect that there are sooo many places where extension
modules in packages are not supported that it is just a tiny detail
that they don't work in builtin modules (which, as I said, only have
top-level modules, anyway).
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
