Re: making Python GStreamer plugins work



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.

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. 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.

John



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]