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