Robert Nikander wrote: > Hi everyone, > > I have been playing with metaclasses in Python and thought the > following code was cool... > > It is the signal.py demo with a metaclass. I bet it is pretty easy to > add the metaclass attribute to the C PyGObject class somewhere in > gobjectmodule.c... then we could forget about type_register and the > __metaclass__ attribute. > > Of course you can also look at the 'dict' from the class statment and > create signals and and properties according to __signals__, > __properties__, > or something like that, but I understand those features are already > in CVS, > though I don't know if they were implemented using a metaclass or not.
I had thought about this a bit, but it looks like it would be more likely to cause questions than with the explicit type_register call. When subclassing from an existing widget, you can't chain up to the parent __init__ function -- it is necessary to call __gobject_init__ or GObject.__init__ instead, in order to create the correct type (otherwise, none of the signals/properties you added will be visible). Also, overriding signals is done when subclassing from a C type, compared to subclassing from another python GObject. Also, creating subclasses without creating a new GType is sometimes useful -- lots of programs using stable pygtk. I don't know if all of these cases people will want new GTypes. I might be totally wrong, and people would prefer the automatic type registration on class creation behaviour. It would be fairly easy to create a metatype for GObjects (just subclass PyTypeType and override tp_call). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
