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

[Martin v. Loewis]

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

In Python, on Unix, multiple and different copies of expat are a
problem only if you have one statically linked into Python; PyXML will
then refuse to install. If multiple extension modules link expat,
those are opened with RTLD_LOCAL, so they won't interfere with each
other. Problems will occur once people decide that building expat as a
shared library is a good idea; at a minimum, you need different
sonames for them.

Don't know what the status on Windows is - expat *is* typically a DLL
there, so that is a bit more tricky; the expat maintainers better
start to put a version number into the DLL name.

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

The pyexpat module (pyexpat.pyd) shipped with BeOpen Python 2.0 relies
on the expat DLLs (multiple!). The pyexpat.pyd shipped with the PyXML
binary distribution has expat linked statically, so it won't care
about any expat DLLs. If PyXML is installed, the pyexpat shipped with
Python won't be used anymore (unless you explicitly request it - it is
not overwritten).

> does pyexpat make any changes relative to the SF expat distribution?

Not sure what the question means. pyexpat.c can now use features of
multiple expat versions (although you can't distinguish 1.1, 1.2, and
1.95.1 programmatically - in the expat CVS, there is a version #define
now). The expat version being used is used unmodified, except perhaps
for the build procedure: in PyXML, we have expat 1.2 incorporated, so
we build it ourselves. There are actually a few changes compared to
expat 1.2, e.g. to not use C++-style comments; the stock version will
work fine as well.

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

On Unix, nothing bad will happen. On Windows, it would be best to use
the PyXML build process: link it statically. Or, if building from
sources, use the same expat version to build all of them.

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

I'm not planning for the eternity. For the forseeable future, yes.

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

No. Normally, you cannot replace a module from the standard
library. For the XML package, there was a special exception. It is
only ugly when you look at it; normally, you don't need to be concern
with it.

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

Because Microsoft has frozen the API of msvc42.dll. Actually, this
library is only needed for old applications; new applications link
with msvcp60.dll (or msvcp60d.dll or msvc60u.dll or ...).

You must rename the library if you change the API - even if it is a
change to a function "that nobody uses". Such a change happened for
2.1 - the function that creates frame objects takes two additional
parameters (lists of cell objects).

> obviously someone chose to make all the 2.1 betas and alphas share a
> dll name.

Yes, that might cause binary incompatibilities - if you have build
programs against the betas, you need to rebuild once the final release
happens.

> 1. perl changes its second version digit far less often.

That is simply not true. Over a period of eight years, there where 6
Python releases (I think); only three of them resulting in Win32 DLLs.
python15.dll lasted 2.8 years or so (since January 1998).

> if python is going to be doing a dot rev every 3 months, things will
> be painful.

It won't.

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

Distutils is rather the equivalent of makefile.pl, not of CPAN; I
agree that upgrading 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.

Won't this break terribly if the ABI has changed (or even if just a
different set of options was used to build the previous release)? I
always tell perl installations not to look for old versions of the
modules; everytime I use CPAN, it essentially reinstalls my entire
system (as far as perl modules go). It might be better, but it isn't
perfect, either...

Regards,
Martin