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

[Martin v. Loewis]

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

It depends on what a "dot rev" is. Python 2.0.1 would be a pure bugfix
release; 2.1 isn't.

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

How does that work? Are these other perls also using perl56.dll? If
they had been using, say, perl55.dll, are the binary modules not
linked with perl55.dll? If they are, how does perl manage to use
perl56.dll and perl55.dll simultaneously?

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

Indeed. Python 2.0 was a major change over Python 1, and a number of
things needed to be fixed/extended/improved/completed, which caused
2.1 being released only five months after 2.0.

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

So you are saying that different perl versions share the same toplevel
lib directory, but do not share any library files? Why is that a good
thing?

In Python, if you want to share packages between Python installations,
you can put them in <prefix>/lib/site-python (instead of
<prefix>/lib/python<version>/site-packages). That, of course, requires
that the package actually works with all the Python versions
installed. Distutils cannot know for sure, so it installs packages
into site-packages by default.

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

That is the case with Python also.

Regards,
Martin