On Wed, Sep 12, 2001 at 01:56:46PM +0800, James Henstridge wrote:
> One request that has come up many times is to drop the "Gtk" prefix from
> the widget class names in pygtk.
>
I'm positive to this. A little perl^H^H^ython script can do most of the
conversion. And programs has to be ported to pygtk anyway.
> In the past, the answer has been that it would cause name space pollution
> for people doing "from gtk import *". However for the development series,
> using "from gtk import *" is discouraged more so than in the stable series
> (when the development branch goes stable, I intend to have all examples
> converted over to using "import gtk").
>
> As this would cause large source incompatibility, I am looking for
> people's opinions about such a change (I haven't decided which way I feel
> about this issue yet).
>
> To help people get a feel for the two options, I made the required
> modifications to pygtk on a branch in CVS (short-class-names-branch),
> converted the pygtk-demo example over and spun a tarball of the result.
> It is available here:
> http://www.gnome.org/~james/pygtk-1.99-short-class-names.tar.gz
>
> It is identical to the 1.99 release (other than the class naming), so
> should compile and run with the 1.3.7 release of gtk+.
>
> The main changes are:
> pango.Pango* -> pango.*
> gtk.Gtk* -> gtk.*
> gtk.Gdk* -> gtk.gdk.*
>
> and the functions in the gtk module that were from GDK have been moved to
> gtk.gdk module.
>
> There is one other major change that I am considering (although it will
> affect the API far less) -- using the new python 2.2 features instead of
> ExtensionClass. I haven't started looking at how easy such a change would
> be (probably not that hard -- it would mainly be changes to the code
> generator and the gobject module). The change would have the following
> pros:
>
> - no longer require ExtensionClass. The current development version of
> pygtk requires a modified version of ExtensionClass (that allows
> creating subclasses in C). This ExtensionClass is not currently in
> sync with the Zope version, as I haven't been able to get the changes
> merged back in. ExtensionClass often needs to be updated to support
> new python releases.
>
> - Using the native class support in python 2.2 will probably integrate
> better with python (there are a number of gotchas when using
> ExtensionClass).
>
> Cons are:
>
> - Require python 2.2. Older versions of python won't work. (of course,
> most Linux distros are still shipping 1.5.2 as the default python
> installation. By the time Red Hat, etc make a binary compatibility
> breaking release, 2.2 should be out).
>
> - Some currently used ExtensionClass features may not have equivalents
> in Python 2.2's new code.
>
> Comments on this issue are also welcomed (keeping in mind that I haven't
> even started testing it on a branch yet).
I'd say go for it. But then I only maintains some 10k lines of
noncritical already buggy code... The faster 1.5.2 get dumped the better.
One negative thing is that python 2.2 will probably not make it into
woody.
>
> James.
>
> _______________________________________________
> pygtk mailing list [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
>
--
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
