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

[Mark D. Anderson]

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

true enough. i didn't know that changing function signatures was "allowed"
in dot revs of python (versus only adding functions, possibly with "Ext" or "2" at the end...).

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

i meant perl changing the version digit in the dll in such a way as to invalidate existing
binary modules. my perl56.dll has worked with binary modules built with other
perls, and i have upgraded my perl56.dll repeatedly with different activestate releases.

in retrospect, i'm not actually sure there is much different here between python
and perl in binary compatibility. it is just that python is bringing out 2.1 shortly after 2.0,
while the perl world has been effectively frozen for a year or so while the powers that be
contemplate perl6.

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

on unix, perl embeds the perl version in the site_perl hierarchy, so that 
multiple perl installations can share that same hierarchy. then the import search
path is initialized appropriately in any perl using that site_perl so it only "sees"
the site_perl branches that match its version.

windows perl doesn't do that, and it should. 
historically activestate has horked up the install directory structure in various
ways deviating from the unix one; it seems to have gotten more similar over
the years. 

-mda