Re: Python GObject Introspectation Syntax

[Tomeu Vizoso <tomeu tomeuvizoso net>]

On Wed, Oct 6, 2010 at 10:09, Steve Frécinaux <code istique net> wrote:
> On 10/06/2010 09:27 AM, Tomeu Vizoso wrote:
>>
>> On Wed, Oct 6, 2010 at 09:21, Steve Frécinaux<code istique net>  wrote:
>>>
>>> The more complicated thing will be to efficiently find "Gtk-1.0.typelib"
>>> out
>>> of "gtk".
>>
>> Should we expect that one day there will be enough typelibs to make
>> that really a challenge?
>
> Well, I count 352 .so's in my /usr/lib. If g-i really takes off and gets
> used for python extensions as it is soo easy to do, I'd guess it would not
> be unfair to ask for efficiency with around 300 typelibs. It's probably
> still few enough so we can pack all of this in a sorted list of ('gtk',
> 'Gtk-1.0.typelib')-style values and live with it.

Well, g-i is going to remain constrained to gobject-based libraries,
which should be a relatively small subset.

>> So if nobody comes with a good argument against, I guess we need a patch
>> ;)
>>
>>> While we are at it, a very nice thing would be to allow old-style
>>> constants
>>> to be handled as well, but I think it's going to be even more complicated
>>
>> Which issues do you anticipate?
>
> I don't know, you told me it wasn't doable ;-)

All I remember is the issue with clashes at the toplevel namespace,
but I think we agreed that this wasn't a real concern because of how
this same clashes would happen in C as well.

> I would have expected we
> could just cycle around all the enum and flag types and define the old-style
> constants from there (but it's more work at import time and breaks laziness)

I guess we could infer the container type from the prefix, not sure if
we can do that in pygobject or if it should be g-i to do it.

Regards,

Tomeu