Re: Using python + pygtk in Desktop modules
- From: Sean Middleditch <elanthis awesomeplay com>
- To: Murray Cumming <murrayc murrayc com>
- Cc: "desktop-devel-list gnome org" <desktop-devel-list gnome org>
- Subject: Re: Using python + pygtk in Desktop modules
- Date: Tue, 28 Sep 2004 16:27:20 -0400
On Tue, 2004-09-28 at 23:44 +0200, Murray Cumming wrote:
> I think you're saying that 2.3.2 might break apps that previously used
> 2.3.1. Even if it's happened by accident in the past, I'd be very
> surprised if this is policy.
No. I'm saying 2.3 might break apps that ran in 2.2.
> You don't seem to be justifying that statement. But again, the Bindings
> make just as much of a fuss about API and ABI stability as the Platform.
> It's not a dumping ground for stuff that breaks applications. I've put
> the Bindings maintainers through interrogations such as this one to make
> sure of that.
Alright. My fault for confusing the Bindings/Platform release
priorities sorry.
Regarding ABI stability... given that we maintain ABI stability, and
that Python breaks that, as third-party developers cannot target GNOME
but must target a specific OS/release, does that not break the entire
goal of ABI stability? Again, if you expect everyone to repackage
everything for every OS/release, why do you bother with ABI stability?
It's 100% worthless if you're saying users are forced to recompile and
repackage every app for every OS/release.
The stable ABI is maintained for a reason. For the same reason that,
for example, the LSB exists and forces a stable ABI between various
Linux distributions.
That reason is to allow third-party apps to be written, compiled, and
packaged just once, and let them install and run everywhere. That is
entirely the point of ABI stability.
>
> > 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.
>
> I don't like that solution, because it requires all packages to be
> updated, and it prevents 2 apps using 2 versions of python from
> coexisting.
It's the exact solution you mentioned above. I think I phrased it a
little poorly, though - my apologies.
>
> [snip]
> > 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.
>
> Again, you need to give a specific example, and not of something that we
> would not be stupid enough to do.
Python release notes...
Here's a list of language-level incompatibilities for 2.1 to 2.2.
http://www.sourcekeg.co.uk/www.python.org/2.2.3/bugs.html
>
--
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]