Re: Proposed Modules, My Take

[James Henstridge <james jamesh id au>]

Sean Middleditch wrote:

> On Wed, 2005-01-19 at 19:53 +0000, Mike Hearn wrote:
>  
>
> > On Wed, 19 Jan 2005 11:16:45 -0500, Sean Middleditch wrote:
> >    
> >
> > > If a module isn't going to offer a stable ABI throughout the major GNOME
> > > release series then it doesn't belong anywhere except the Desktop
> > > release.
> > >      
> > I think the problem here is that people assume the bindings operate under
> > the same rules as the developer platform - that is what makes intuitive
> > sense. After all Apple don't say "Cocoa is stable unless you use Java" -
> > the Java bindings operate under the same rules as the 'native' Objective-C
> > APIs do.
> >    
>
> According to this:
> http://developer.gnome.org/dotplan/bindings/rules.html
>
> New versions must not break ABI.  While PyGTK itself does not break, it
> does heavily depend on the ABI of Python and that *does* break.  It's
> like saying it's alright if GTK+ is stable but glib can be unstable.
> Unless each release of GNOME has a standard Python version that must be
> available with that release, PyGTK would be breaking the spirit of the
> rules, if not the exact letter of the rules.
>  
There are two interfaces you could be talking about here.  One of them 
is the the one exposed to Python applications and is very stable.  The 
Python developers take backward compatibility very seriously here.

The other interface is to C extensions, which has maintained a strong 
level of source compatibility over subsequent versions of Python.  
However, extensions should be recompiled when a new 2.X version of 
Python is installed (e.g. when moving from 2.3.x to 2.4).  This does not 
affect pure Python programs though.

It is also worth noting that some of the improvements in Python over the 
years have been made in response to the needs of large extensions like 
pygtk.  If you froze the Python version requirement for pygtk to the 
version available when Gnome 2.0 was released, you'd never be able to 
write a non-broken threaded pygtk program until Gnome 3, for instance.

You really do seem to be holding language bindings to a higher standard 
than other code here, and I don't see the benefit.  Do you also want to 
require that GTK+ be compiled on a particular version of glibc so that 
it doesn't end up using newer versioned symbols, and prevent you from 
moving that libgtk-x11-2.0.so.0 file to an older system?

James.