[XML-SIG] saxlib, xml, _xmlplus, etc.

[Mark D. Anderson]

> Sorry for the confusion. Please notice that you are a "rare case";

i've heard that before :).

> As you can see from the "last release" date on the saxlib page, this
> package is quite outdated. It has been incorporated in PyXML in the
> past, and is known today as "Python SAX version 1".

it'd be nice if lars updated his page to note this. though it is old, there are still
quite a few links pointing to his page, not to pyxml or python 2.

> In addition to the API spec, there is a number of SAX drivers in each
> package. The saxlib has the SAX1 drivers, Python 2 only has a Expat
> SAX2 driver, and PyXML has SAX1 and SAX2 drivers (in the latter
> category, only Expat and xmlproc).

another useful faq somewhere would be about expat. this is actually
a PITA for the perl world too right now -- apache links in expat
(optional, but not if dav is linked in), and then XML::Parser pulls in another expat,
and probably both are different from the latest one, things start crashing.
they all used to be statically linked but can now use a separate package direct from
the sourceforge expat project. (I'm one of the unfortunate few who actually
understands all this, and i'm the first to admit i haven't done my part in writing it up).

so for python, suppose you wanted to upgrade to the latest sourceforge expat.
is that possible? is the expat dll relied upon by any core python modules?
does pyexpat make any changes relative to the SF expat distribution?
what happens if you want to use mod_py and an apache with expat linked in?
or worse yet, suppose you wanted to link mod_py and mod_perl and mod_dav into apache?

> PyXML is meant as a strict superset of the Python 2 XML offerings; in
> all aspects that are present in Python 2, PyXML should behave
> identical (as far as possible and reasonable).

is this situation going to remain indefinitely?
does this mean that any other "foo" sig who produces something part of python
core is going to have to do a similarly ugly python/_fooplus ?

> In the README of PyXML itself, you'll notice that saxlib 1.0 is
> included. 

true, though generally people like to know what is in a package before
they download it...

> > if binary packages are obsoleted by dot revisions in the core, it is
> > going to be painful for everyone.
> 
> Unfortunately, that is a specific form of "DLL hell"; there is not
> much that can be done about it except guaranteeing that conflicting
> things are not used together - the installer refusing to install the
> package anywhere else is one aspect of that.

well, 2.1 doesn't *have* to call its dll python21.dll
after all, why do we all have msvc42.dll on our windows boxes?
that is just one choice about how to force incompatibility.
obviously someone chose to make all the 2.1 betas and alphas share a dll name.

what win32 perl is currently doing is a perl56.dll.
that would seem similar to what python is doing today, except that:
1. perl changes its second version digit far less often. that one dll works with all but the earliest
activestate 600 series, spanning well over a year. if python is going to be doing a dot rev every 3 months,
things will be painful.
2. python distutils is not very close yet to the power and convenience of perl's ppm or
"perl -MCPAN -e shell" so upgrading binary packages over the net is harder.
3. perl has a more sophisticated import search facility than python's, which
attempts to pick the highest version of a module which is applicable, for lib
directories structured a certain way, making it possible to have a single lib directory shared
among multiple perls.

> > btw again, another faq should be how urllib deals with win32 drive letters.

i'll start a new thread on this.

-mda