[gst-devel] Re: making Python GStreamer plugins work

[Owen Taylor]

On Sat, 2005-04-30 at 12:25 -0600, John Ehresman wrote:
> Owen Taylor wrote:
> > I think it should be possible to do basically the same thing in Python
> > by creating the GObject out of GObject.__new__() rather than out of
> > GObject.__init__(). 
> 
> This would break backwards compatibility.
> 
> >  __new__() calls g_object_new()  calls ... ->init() which allocates
> >    the python object and binds it to the GObject
> > 
> > This is not 101% compatible with the current system but all the
> > incompatible cases I can come up with are pretty artificial (*)
> 
> It would break this:
>    class MyButton(gtk.Button):
>      def __init__(self):
>        gtk.Button.__init__(self, 'My Default Text', True)
> 
> This could be rewritten to use __new__, but it would need to be rewritten.

I think this still works ... since the GObject is *always* created in
the __new__ callback, GtkButton's __init__ looks like:

  def __init__(self, label=None):
    if label:
       self.set_label(label)

Constructor arguments that set CONSTRUCT_ONLY properties may be a
problem (when aren't they...)

> > But in such cases all GObject additions would be would be a slightly
> > cleaner version of John's technique of passing data to the constructor
> > via magic properties... whether the constructor triggers GObject
> > creation or whether GObject creation triggers the constructor is
> > going to make a difference in how things are ordered.
> 
> Yes, using a magic property is a bad idea -- there's a reason the patch 
> was never committed.  It's better to use thread local storage, although 
> that depends on no callback occurring between the call to g_object_new 
> and the GType constructor. 

I don't think you can make that assumption ... the init() function of 
a superclass might result in the creation of another Python object. 
(It's a little contrived, but 

>  For bindings that have the language specific 
> constructor trigger GObject creation (like pygtk), it would be better to 
> have a factory function that would get all the properties passed in and 
> be responsible for returning a valid GObject.

That's basically what constructor() is ... all it seems you might want
would be 

gpointer g_object_new_with_data (GType        object_type,
                                 gpointer     data                     
                       		 const gchar *first_property_name,
                                 ...) G_GNUC_NULL_TERMINATED;

and a hidden fourth parameter to constructor(). (Compatible by the
"OK to call with more parameters" quasi-standard that we depend upon in
various places. *Except* that any classes deriving from the class
have to provide the fourth argument when chaining up. Not a problem
here, really.)

But while this would allow you to do the GObject/Python hookup to
either a newly created or existing Python object it has certain ordering
problems - 

 - The naive implementation would try to set implemented-in-Python
   CONSTRUCT properties before the Python/GObject hookup was done.
   You'd have to strip them out from the list of construct properties
   before chaining up, chain up, do the hookup, then set the Python
   construct properties.

 - The problem with chaining up to the superclass's __init__ with
   parameters exists if you call __init__ at any point, since the
   __init__ function might attempt to chain up with parameters
   even if no parameters were passed in.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20050502/6c6db468/attachment.pgp>