Extensions and Backwards Compatibility

[Aleks Jakulin]

Checking the Google archives, there has been much discussion about breaking
backwards compatibility. I'm quite happy with the development team efforts with
regards to that in the Python code (__future__): even so, as an ordinary user
I'd personally prefer major steps every 5 years, and not several migrations a
year, but this could harm the development effort and its sustainability.

But the situation with the extensions is critical. I have developed a few of my
own extensions for doing data mining with Python, and this year, the maintenance
effort has become annoying. They are not the crux of my work, just a little bit
of community work. The transition from 2.0 to 2.1 has been easy, and done in an
afternoon (I had to seek out and download the new versions of a bunch of
libraries I otherwise use, python, python source, orange, scientific, numeric,
PIL, winall, pyqt, pyqwt, ODBC extensions, two egenix extensions, etc., you get
the image) The transition from 2.1 to 2.2 required a similar downloading effort,
but a simple recompile proved to be insufficient, there are new crashing bugs
during module initialization. I'm even beginning to doubt whether to continue
maintaining these extensions.

There has been some discussion on what to do regarding extensions. Some of the
proposals were terribly low-level (pointer arrays). Perhaps there is a simpler
solution: separate python.dll/lib into the language module (dll/so+lib) and the
gateway module. The language module changes often, and that's life. However, the
gateway module changes rarely, and could be engineered to be such. However, I'm
not familiar enough with the internals to claim validity of the proposal. Any
comments?

Best regards,
            Aleks Jakulin