Re: [pygtk] PyGObject directory issue again, taking a stand

["Dieter Verfaillie" <dieterv optionexplicit be>]

Quoting "Tomeu Vizoso" <tomeu sugarlabs org>:
> > > Why would that be a kludge? For maintainability reasons, I tend myself
> > > to introspection-only,
> >
> > Up until now I had the impression that we were going to be supposed to work
> > like that: use on of both, but never both systems together. So the point of
> > the "do not mix" warning/error I suggested now seems more like a display of
> > my ignorance than anything else. It's never too late to learn, I guess :)
>
> Trouble happens when static and introspected wrappers for the same
> classes mix just because they most often have different APIs.

Yeah, I've started to see the light on that a couple of messages ago :)

> Both kind of wrappers use a metaclass that inherits from GObjectMeta
> so they are in theory compatible, in practice they aren't because the
> writer of the static wrapper usually chose to implement a slightly
> different API than what would be introspected.

So every class that gets defined (either dynamically by gi or on
import time for static bindings) passes through the GObjectMeta
metaclass eventually? Then some form of "namespace protection"
could maybe in theory be implemented there (comparing the namespace
defined in the gir files with the "prefix" of __gtype_name__ or
something like that). Just a thought, didn't investigate if the above
might be feasible or not...

Some form of protection like the above could be helpful, but on the
other hand are we really going to see that kind of mixing a lot in
practice? And is the mixing of static/introspected bindings something
that will survive long enough into the future to warrant the implementation
of such a warning and the overhead it implies?

Looks like I'm seeing the light :)

> > > but some people (actually, gstreamer
> > > developers) have shown concern about the extra overhead during
> > > invocation
> >
> > gi compared to gst-python?
>
> Yes, the static bindings already know at compile time how to marshall
> the python args to C, with introspection we need to make that decision
> at runtime and is not cheap. Johan has explored generating wrappers at
> runtime with LLVM:
>
> http://git.gnome.org/browse/pygobject/log/?h=llvm

Good to know the extra invocation overhead is something under
investigation. That means maybe someday the difference could
become negligible leaving no reason for the gstreamer devs'
concers (and their preference for mixing gst-python with gi), right?

> > >  because there are server-side users of gstreamer that don't
> > > care much about startup cpu and memory usage.
> >
> > I suspect a typo on your part, but if they don't care then why is the
> > extra overhead important?

Finally, I understand what you meant :)
Server-side gst users don't care if the import takes a whole second or
less. They care about the invocation overhead.

> One consequence of the move to gi is that we can decide when to load
> wrappers. With static bindings we load all classes and methods
> regardless of whether will use them or not, which turned out to be too
> expensive for desktop apps because of the slower start times and high
> (private) memory usage.

Yeah, I noticed the difference in import time...

mvg,
Dieter


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.