Re: ANNOUNCE: pygtk-1.99.8

[Johannes Stezenbach <js convergence de>]

On Thu, Mar 21, 2002 at 09:22:38PM +0800, James Henstridge wrote:
> Thomas Leonard wrote:
> >Very nice. I like the interface much better than the 1.2 one. However, I'm
> >still worried about backwards compatibility. I have quite a lot of pygtk
> >1.2 programs (sketch, pythontheater, pysol, etc), and I've written many of
> >my own which are now installed on other people's computers.
> >
> I have explained this to you before.  The difference between the C and 
> Python is that the names of modules are part of the API.  Changing a 
> module name means doing many changes to many pieces of source code. 

You are already changing the pygtk API, so changing the module
name from "gtk" to "gtk2" seems natural. As the module name in
python is part of the API, this is just one more API change.

Also, to use the new pygtk, applications will have to be changed
anyway. If you want to minimize changes you could do:
	import gtk2 as gtk

This leaves the application in control which API version it
wants to use.

> There are a number of ways to parallel install the two versions of pygtk:
> 
>   1. install the two pygtk's to separate directories, and set the
>      PYTHONPATH environment variable to a suitable value.  Most
>      substantial python programs already use a shell script to
>      bootstrap, which sets PYTHONPATH to give access to the rest of the
>      modules in the app.  Adding an extra directory is not a big deal.
>   2. If you have multiple versions of python on the system, you might
>      decide to install different pygtk versions on each (you won't be
>      able to install new pygtk on any pythons < 2.2, for instance).

IMHO it would be best if one could install both versions of pygtk
in parallel with the same python version, without any PYTHONPATH
trickery. Both of your approaches require that everyone who installs
an application based on pygtk would have to create a wrapper
script (or otherwise configure PATH and PYTOHNPATH) so that
the correct version of python and/or pygtk is used.

[snip]
> >	import gtk
> >	w = gtk.GtkWindow()
vs.
> >	import gtk
> >	w = gtk.Window()
> >
> People have been asking for this change for years.  The switch to 2.0 
> gave an opportunity to fix many of the problems with pygtk's 
> infrastructure.  The new codebase is much more maintainable, and 
> hopefully nicer to use.

The new API is better. Good. But having two incompatible
modules with the same name is a crime.
How about:
	import gtk2 as gtk
	w = gtk.Window()


> >Also, both of the first two options leave us open to everything breaking
> >again when 3.0 comes out.
> >
> I doubt the changes to pygtk will be as drastic when we move over to 3.0 
> (whenever that happens).  I am a lot happier with the new codebase, and 
> think it will adapt well in the future.

If API changes are backwards compatible the usual way is
to have a gtk.version that applications can query before
trying to use new functionality. If API changes are incompatible
it is a good idea to be able to install multiple versions
in parallel and leave the application in control about which one it
wants to use. In python this implies that the module (or package)
must be renamed.

> (who wonders what people would have thought if they were told to run sed 
> 's/Gtk/Gtk2/g;s/gtk/gtk2/g' on their C programs to upgrade to gtk 2.0)

The gtk-2.0 C API is backward compatible to the gtk-1.2 C API.


Regards,
Johannes