For 1.6, the XML-SIG wants to submit a few more things, mostly a small
SAX implementation. This currently lives in xml.sax.*. There are
other subpackages around such as xml.dom, xml.utils, and so forth, but
those aren't being proposed for inclusion (too large, too specialized,
or whatever reason).
The problem is that, if the Python standard library includes a package
named 'xml', that package name can't be extended by add-on modules
(unless they install themselves into Python's library directory, which
is evil). Let's say Sean McGrath or whoever creates a new subpackage;
how can he install it so that the code is accessible as xml.pyxie?
One option that comes to mind is to have the xml package in the
standard library automatically import all the names and modules from
some other package ('xml_ext'? 'xml2') in site-packages. This means
that all the third-party products install on top of the same location,
$(prefix)/site-packages/xml/, which is only slightly less evil.
I can't think of a good way to loop through everything in
site-packages/* and detect some set of the available packages as
XML-related, short of importing every single package, which isn't
going to fly.
Can anyone suggest a good solution? Fixing this may not require
changing the core in any way, but the cleanest solution isn't obvious.
--
A.M. Kuchling http://starship.python.net/crew/amk/
The mind of man, though perhaps the most splendid achievement of evolution, is
not, surely, that answer to every problem of the universe. Hamlet suffers, but
the Gravediggers go right on with their silly quibbles.
-- Robertson Davies, "Opera and Humour"
SAX implementation. This currently lives in xml.sax.*. There are
other subpackages around such as xml.dom, xml.utils, and so forth, but
those aren't being proposed for inclusion (too large, too specialized,
or whatever reason).
The problem is that, if the Python standard library includes a package
named 'xml', that package name can't be extended by add-on modules
(unless they install themselves into Python's library directory, which
is evil). Let's say Sean McGrath or whoever creates a new subpackage;
how can he install it so that the code is accessible as xml.pyxie?
One option that comes to mind is to have the xml package in the
standard library automatically import all the names and modules from
some other package ('xml_ext'? 'xml2') in site-packages. This means
that all the third-party products install on top of the same location,
$(prefix)/site-packages/xml/, which is only slightly less evil.
I can't think of a good way to loop through everything in
site-packages/* and detect some set of the available packages as
XML-related, short of importing every single package, which isn't
going to fly.
Can anyone suggest a good solution? Fixing this may not require
changing the core in any way, but the cleanest solution isn't obvious.
--
A.M. Kuchling http://starship.python.net/crew/amk/
The mind of man, though perhaps the most splendid achievement of evolution, is
not, surely, that answer to every problem of the universe. Hamlet suffers, but
the Gravediggers go right on with their silly quibbles.
-- Robertson Davies, "Opera and Humour"