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 -- http://mail.python.org/mailman/listinfo/python-list
