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

[Owen Taylor]

On Fri, 2005-04-29 at 21:55 -0400, muppet wrote:
> On Apr 29, 2005, at 8:53 PM, Benjamin Otte wrote:
> 
> > - And here's the crux of the patch and where the most nastiness comes
> >   from: Allow classes that are derived in Python to be created with
> >   g_object_new from all C code. And handle the refcounting issues, too.
> >   It works, but it's ugly. See the patch for implementation details.
> >
> > I believe the object creation and destruction process for this kind of
> > objects requires some support from GObject to work nicely that  
> > currently
> > just does not exist.
> 
> I don't claim to recall or understand the details of how pygtk creates  
> objects, but i don't agree that there's support missing from GObject  
> for C-driven creation of instances implemented by a scripting language.
> 
> In gtk2-perl, all perl-derived GObject types are created by calling  
> Glib::Object::new(), a no-frills wrapper for g_object_new().  The GType  
> system does its work, normally, and when it gets to the instance-init  
> function for the perl-derived type(s), the standard function for  
> marshaling a GObject to perl creates the initial wrapper and bolts it  
> to the C object.  This ensures that the wrapper exists in your  
> INIT_INSTANCE so you can add data to the instance.

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__(). 

 __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 (*)

Some languages which would have more of a problem with
the way GObject works ... in fact, older versions of Python before
the introduction of __new__ probably fell into that category. 

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.

Regards,
						Owen

(*) E.g. set some fields in your __init__ method *before* chaining
    up, then rely on those fields being set in do_set_property()
    for a construct property.

-------------- 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/6d03270b/attachment.pgp>