Re: GNOME 2.20 Python version

[Shaun McCance <shaunm gnome org>]

On Tue, 2007-03-13 at 18:11 +0000, Gustavo J. A. M. Carneiro wrote:
> On Ter, 2007-03-13 at 12:52 -0500, Shaun McCance wrote:
> > On Tue, 2007-03-13 at 17:38 +0000, Gustavo J. A. M. Carneiro wrote:
> > > On Ter, 2007-03-13 at 16:57 +0100, Lo�Minier wrote:
> > > > On Tue, Mar 13, 2007, Elijah Newren wrote:
> > > > > Unlike GNOME and Linux, Python does not use odd version numbers for
> > > > > development versions.  Thus 2.5 is the latest production version of
> > > > > Python, rather than the latest development version.
> > > > 
> > > >  I know 2.5 is a stable release; my point is that this needlessly raises
> > > >  the bar to build GNOME: anyone is free to build GNOME with whatever
> > > >  version of libc6, gcc, or python that one wants to catch some bugs (in
> > > >  GNOME or in these projects), but imposing the python version to be so
> > > >  high by default seems a gratuitous change.  3 out of 5 Ubuntu releases
> > > >  do not have Python 2.5 by default, no Debian release has it and the
> > > >  next one wont have it.
> > > 
> > >   I am not proposing that GNOME modules using Python should require a
> > > minimum Python version of 2.5.  I am only proposing that "jhbuild
> > > bootstrap" install the python 2.5 tarball instead of python 2.4.  The
> > > effect of this change is:
> > > 
> > >   1. We start putting more emphasis on testing GNOME-over-python2.5
> > > rather than GNOME-over-python2.4 (the latter has already been
> > > extensively tested over the years, while the former hasn't);
> > > 
> > >   2. We require that GNOME modules using Python make an effort to work
> > > on Python 2.5, in addition to Python 2.4.
> > > 
> > >   I think primarily it's a matter of which version of python we prefer
> > > to test.  I say we test GNOME with python 2.5 because it's the new
> > > stable version of python and python 2.4 is not maintained any more.
> > 
> > If a program works correctly with Python 2.4, is there
> > actually a danger of it not working correctly with 2.5?
> > That sounds broken.
> 
>   Yes, there is a lot of danger of it not working with 2.5 in particular
> in 64 bit systems.  Python does not guarantee strict API/ABI
> compatibility; that issue has been discussed extensively in the past in
> this very mailing list.  Python changes API and ABI of extension modules
> and even the language itself, albeit very slowly so as to not cause too
> many headaches.

Yes, looking through my archives, it seems we had a very long
discussion about this in September/October 2004, when we first
proposed allowing Python in the desktop.  People were concerned
we would have problems like this.

>   In this case, however, Python in 2.5 decided to change the extensions
> API to use "long int" rather than "int" in a lot of places.  In LP64
> systems that represents a major ABI change.  This change, however, only
> gives few compilation warnings for some cases, or in other cases not
> even a compilation warning is given (like the s# convertion specifier in
> PyArg_ParseTuple) and the programmers have to pay attention to the code.
> Sometimes, only in runtime can errors be caught.
> 
> > 
> > I worry that this move would result in programmers using
> > 2.5-only features.  Our intrepid testers wouldn't notice,
> > because they're building from jhbuild.  But we'd create
> > an effective 2.5 dependency that our distributors would
> > have to deal with.
> 
>   1. Distributions that are bleeding edge enough to include GNOME 2.20
> but still using Python 2.4 are just... crazy :|

Be that as it may, if 2.4 is our officially recommended
version of Python, then it has to work.  Hence, we should
test with it.

>   2. For the N-th time, I am not advocating dropping support for Python
> 2.4.  I am saying that it is important that we test Python 2.5, more so
> than testing Python 2.4.

I understand that.  This is the scenario I'm talking about:
Julie is the maintainer of Plankton, an application written
in Python.  Her build and testing environment is switched to
Python 2.5, and she discovers an incompatibility that makes
Plankton not function.  She fixes the problem.

Unfortunately, the change she made is not compatible with
Python 2.4.  Since she's building and testing on Python 2.5,
she doesn't know this.  Hence, Plankton is now broken under
Python 2.4.  This is particularly annoying because 2.4 is
the officially recommended version of Python for Plankton.

You should always test with your minimum requirements.

--
Shaun