Re: Using python + pygtk in Desktop modules



On Tue, 2004-09-28 at 15:23 -0400, Sean Middleditch wrote:
> On Tue, 2004-09-28 at 22:44 +0200, Murray Cumming wrote:
> > On Tue, 2004-09-28 at 13:26 -0400, Sean Middleditch wrote:
> > > I am not talking about the Python app ABI, I'm talking about the C API
> > > Python exposes.
> > 
> > I'm not personally that concerned with cross-distro packages, and I
> > don't think they should be a big factor for us yet, but:
> > 
> > Are you saying that the Python C ABI changes between minor releases? I
> > doubt that, so I don't think that's an obstacle to cross-distro packages
> > - just link to a specific version of python's C ABI, such as 2.2 or 2.3.
> > Surely that's possible?
> 
> The modules have to be installed into a minor-version specific dir,
> i.e., /usr/lib/python/2.3/site-packages.  And if you try to just copy a
> compiled module from 2.2 to 2.3, it might actually work (in both cases
> I've tried it did, actually) but Python complains very loudly about it,
> indicating that they don't support it.

They specifically don't support it, the fact that the .pyc files exist
at all are an "implementation detail".  The fact that you can run an
application using only the .pyc files is *also* an implementation detail
that should not be relied upon.

> I also looked up in the Python release notes, and indeed the language
> itself *has* changed in the 2.x release series; i.e., apps written for
> an older 2.x release may not work in a newer 2.x release.  I don't write
> a lot of big Python apps, but I do recall being bitten by such a change
> before, in 2.1 I think.  The Python language adds keywords and removes
> deprecated features in minor releases.  I.e. a feature might work in 2.1
> with no warning, give a warning in 2.2 about deprecation, and be gone in
> 2.3.  Third party apps shouldn't have to put up with that.
> 
> If that isn't API/ABI instability, I don't know what is.  ;-)

Read the PEPs that describe language and standard library changes:
backwards-incompatible changes to the standard library require at least
one "minor" release wherein they give a pending deprecation warning.
Additionally, the "minor" releases in Python take about twice as long as
the equivalent stable minor release in GNOME.

Changes to the syntax or semantics of the language itself require at
least one minor release of "from __future__ import feature". 

*snip*

> For apps included in the GNOME Desktop Release, this is workable.  The
> packages can detect which version of Python is currently installed and
> make any changes necessary for the package to work.  The only potential
> problem then is if the package is meant to be moved around.  If everyone
> is of the mind that core GNOME packages are to be OS specific, I guess
> that isn't a problem.  When the OS is upgraded, GNOME will likely be
> upgraded with it.  The only potential problem is if the app required
> some Python 2.2/2.3 feature that's removed in 2.4/2.5, or some new
> keyword is added that causes the app to have a syntax error, or
> whatever.
> 
> Moving an app from an older Python release to a newer release can
> *potentially* have the same sorts of problems you'd see trying to
> recompile a C app as C++.  Often times it'll Just Work(tm).  For some
> particular cases, it won't.

These days (Post Python 2.2, when a number of the API/language stability
PEPs were written), that's largely untrue.  If an app depends on a
Python 2.2 feature, the earliest it could be removed is 2.4, a 2.3
feature, 2.5 and the intervening release would almost certainly make you
aware of the problem.  In fact, if a Python application were written for
Python 2.2 (released December 2001) and included with GNOME 2.0
(released July 2002) it would very likely still run today with no change
on the latest-and-greatest python 2.3 (installation differences not
withstanding, the APIs and language would still work).

In fact, I'd wager that there would be more changes related to the new
APIs introduced in GNOME since 2.0 than fixing Python compatibility
problems.  Hell, if you really want backwards compatibility a
significant number of Python libraries and applications written for
Python 1.5.2 will run unmodified on Python 2.x.

-- 
Shahms E. King <shahms shahms com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B

Attachment: signature.asc
Description: This is a digitally signed message part



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