Re: Using python + pygtk in Desktop modules (was Re: Revisitingthe Gnome Bindings)



> You can expect minor API changes between major
> versions, of course.  That's why the modules dir changes between major
> releases.  That's also why to some people it looks like python is
> breaking the API, while it just had minor API changes but is forcing you
> to recompile every module for the new version.

That sounds like breaking both the API (which == the ABI for Python, I
think) to me.

This is a serious objection, so let's make clear what actually happens:

If I develop and install my app with python 2.2, and then install python
2.3, might my app stop working?

I think I've seen this kind of problem on Red Hat Linux with Red Hat's
system-config-* control panels. Users don't like seeing python errors.

>   Also note that between python 2.2 final and 2.3 final 19 months
> passed.  That's enought time for 3 GNOME major releases!  I think that's
> stable enough for me.

The GNOME Platform, on the other hand, _never_ knowingly breaks API or
ABI. We've worked out a system of parallel-installation for the cases
where we really need to change ABI, so that applications don't break.

>> It's as if the GTK ABI were to break with each minor release version.
>
>   No, it's not.  Python does not break ABI with minor releases.

So, we are talking about major Python releases, but that's still different
to what GNOME normally does.

>   Even if Python doesn't break ABI after another 19 months, pygtk can
> usually compensate for any differences.  It's just like glib
> compensating for API changes in glibc.

Surely, glibc doesn't have a lot of API changes, for obvious reasons.

>  Changes in definitions compiled
> with which defines (_GNU_SOURCE et al), for example.
>
>>
>> When a Python app or lib can be installed on a system running Python 2.3
>> and still work when the machine is upgraded to 2.4, then it would become
>> a much more reliable and serious environment to rely on in GNOME.
>
>   Your distribution should pick a python version for you and stick with
> it.  PyGTK does not switch to a newer Python version unless it is
> already in widespread deployment.

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]