Extensible library packages
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"
Andrew M. Kuchling wrote:
For 1.6, the XML-SIG wants to submit a few more things, mostly a small SAX implementation.
Can anyone suggest a good solution? Fixing this may not require changing the core in any way, but the cleanest solution isn't obvious.
saxlib.py ? (yes, I'm serious) </F>
"Andrew M. Kuchling" wrote:
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?
You could make use of the __path__ trick in packages and then redirect the imports of subpackages to look in some predefined other areas as well (e.g. a non-package dir .../site-packages/xml-addons/). Here is how I do this in the compatibility packages for my mx series: DateTime/__init__.py: # Redirect all imports to the corresponding mx package def _redirect(mx_subpackage): global __path__ import os,mx __path__ = [os.path.join(mx.__path__[0],mx_subpackage)] _redirect('DateTime') ... Greg won't like this, but __path__ does have its merrits ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Tue, 11 Apr 2000, Fredrik Lundh wrote:
Andrew M. Kuchling wrote:
For 1.6, the XML-SIG wants to submit a few more things, mostly a small SAX implementation.
Can anyone suggest a good solution? Fixing this may not require changing the core in any way, but the cleanest solution isn't obvious.
saxlib.py ?
(yes, I'm serious)
+1 When we solve the problem of installing items into "core" Python packages, then we can move saxlib.py (along with the rest of the modules in the standard library). Cheers, -g -- Greg Stein, http://www.lyra.org/
Hi! Andrew M. Kuchling: [...]
The problem is that, if the Python standard library includes a package named 'xml', ... [...] Can anyone suggest a good solution? Fixing this may not require changing the core in any way, but the cleanest solution isn't obvious.
I dislike the idea of having user visible packages in the standard library too. As Fredrik already suggested, putting a file 'saxlib.py' into the lib, which exposes all what a user needs to know about 'sax' seems to be the best solution. Regards, Peter
participants (5)
-
Andrew M. Kuchling -
Fredrik Lundh -
Greg Stein -
M.-A. Lemburg -
pf＠artcom-gmbh.de