Re: Proposed Modules, My Take

[Sean Middleditch <elanthis awesomeplay com>]

On Thu, 2005-01-20 at 09:22 +0800, James Henstridge wrote:

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

Not seriously enough, since it *does* change.  The Python release notes
document those changes readily enough.  ;-)  If Python didn't do that
then I'd have no argument at all.

> 
> The other interface is to C extensions, which has maintained a strong 

I'm not concerned with those; I'm considering the C API an internal
implementation detail for the sake of GNOME apps written against PyGTK.

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

Not true.  Newer versions of GNOME would just depend on newer versions
of Python.  The problem is that then you could well end up with, say,
GNOME 2.12 depending on three versions of Python (since you'd need to
keep the older ones around for backwards compatibility).  I think that's
just a loss that has to be accepted if GNOME wants to depend on software
with a release cycle and management like Python - it's the price you
pay.

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

Two things about that analogy.  First, moving libgtk isn't a problem.  I
don't care if you can move PyGTK between machines - I care if you can
move apps depending on PyGTK between machines.  glibc doesn't have this
problem since you can take apps compiled for GNOME 2.0 on glibc 2.2 and
run them on GNOME 2.10 on glibc 2.3 fine.

The second issue is that glibc sits at a lower level than Python.  You
can't mandate glibc because many OSes that GNOME supports don't even use
glibc.  The libc is, for all intents and purposes, part of the OS.  If
the libc interface breaks, you are effectively running an entirely
different OS platform.

My questions:
 1) Do the Bindings follow the same rules as the Platform or not?
 2) What do you hope to achieve by putting PyGTK in the Bindings
release?
 3) With the breakage and instability that exists, can that still be
achieved?

As I'm seeing things, the answers are:
 1) Yes, according to the Bindings page on the gnome.org site, Bindings
must keep a stable API/ABI just like the Platform, unless they are
marked BETA, which PyGTK is not.
 2) The purpose is to allow ISVs to be able to rely on Python bindings
being available and their apps being able to work on any GNOME system,
the same way an app using the C API can be built for one GNOME release
and run on any machine using that release or later, on the same OS
platform.
 3) Because Python incompatibilities can cause apps to break across two
machines runing the same version of GNOME, ISVs still have to avoid
PyGTK if they want their apps to reliably run, so there's no reason to
include PyGTK in the Bindings.

Either the incompatibility needs to be fixed/worked-around (as simple as
just _recommending_ a Python version!) or PyGTK needs to be kept out of
the Bindings release; stick it in Desktop (assuming you have an Desktop
app that actually needs it).

At this point I think I've stated the same argument six different times
- I'm done.  (Yes, I can hear you all sighing in relief.  ~_^ )  I
really am saddened that just adding one sentence to the documentation
clarifying Python version compatibility is apparently too much to ask.