Python does not play well with others

[Paul Boddie]

John Nagle wrote:
>
>      The real problems are with integration of modules that
> aren't written in Python.  Python-only modules don't have the
> version compatibility problems which C modules do.  Loading
> a Python-only module from an external source is usually not
> a big deal.  Building a C module, especially one with
> dependencies on other components, can be a big deal.
> So, focus on problems with modules which have C
> components.

I think that the integration of certain "popular" extensions into the
Python distribution has been one of the tools employed to mitigate the
version compatibility situation: if the popular stuff gets released
with Python, perhaps fewer people will complain about "C modules"
whose developers/maintainers haven't updated them for the latest
release. I'm not really convinced that this makes for a sustainable
approach, however, since this just becomes a process of accretion
where the core development community must get larger and become very
well-coordinated in order to manage the dependencies within the
software, as well as tracking external dependencies.

Over the years there have been suggestions which might have made the
compatibility situation a bit better: a "Python in a tie" release was
an objective of the seemingly dormant Python Business Foundation;
Linux Standard Base inclusion of Python has been proposed and
discussed. I can't help feeling that without improvements in such
other areas, things like "C module" availability for different Python
versions (and for different versions of related libraries) is mainly
an issue of doing the almost thankless hard work of backporting,
testing and managing different build configurations. Still, there may
be demand for a backports community in all this.

Paul