Re: [pygtk] gtk-1.3 bindings
On Mon, 26 Jun 2000, Fred L. Drake, Jr. wrote: > > For quite a while, I have been passing function pointers around as > > CObjects in the modules (eg. gtk._gtk._PyGtk_API in the 0.7.0 release), > > which means that the different wrapper modules don't need to see each > > other's symbols. > > Excellent! The example of using a CObject as an API container/ > accessor made this look very tedious for the implementor; what can I > do to make this easier to use? It is not that difficult. I swiped the current setup from the numpy guys :) > > > As for symbols from libraries, I think from python 1.5.2, it doesn't use > > the RTLD_GLOBAL flag when loading extensions, so the extensions don't > > pollute the global symbol table. > > Yes, I understand why, I just recall having lots of problems with > the Imlib stuff because of that. That was a year ago, so has probably > been fixed at this point, but I must admit that I've not built any of > this stuff for a while now. I heard from msw that Red Hat reverted that change in their packages. The problem with imlib (which also occurs in gdk-pixbuf) is that libtool-1.3.x doesn't allow linking one libtool library as a dependency for another. The beta version, libtool-1.3b, allows this but doesn't support as many platforms as 1.3.5. > > > What would be nice would be if ExtensionClass integrated better with > > python (so that all the special cases for normal classes work for > > ExtensionClasses). > > I'd be very interested in your comments on what it would take to > make things easier if something like ExtensionClass were available as > part of the core, both from the requirements side and ease-of-use > perspective. ExtensionClass goes most of the way towards having an easy way to create new class like types from C. I had to patch is a bit to get making subclasses in C, which made it good for most of the rewrite. The real problems lie on the python side. Things like isinstance and issubclass don't work on ExtensionClasses. There are similar problems in other parts of the interpeter where there are special case handling with PyInstance_Check (eg in PyObject_Compare). For these ones, it would be nice if either ExtensionClass was integrated and perform the same sort of special cases when PyExtensionInstance_Check() is true as for normal instances, or if the PyInstance_Check() calls were replaced with ones that would return true for both normal instances and ExtensionClass instances (such as checking for an __class__ attribute). I don't know if you want to integrate ExtensionClass into the python core, so maybe the second option would be better. > > -Fred > James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] gtk-1.3 bindings
James Henstridge writes: > Well, this is one of those things where we won't know how many useful non > gui libraries will use the object model until after the glib/gtk 2.0 > release. I have decided to put the GObject wrapper stuff in a separate > module just in case. There's certainly no way to be completely sure. My comment was intended to mean something more along the lines of "I have no idea how much typical C programmers are trying to emulate 'object' behavior," especially since the GKT+ approach is relatively heavyweight, providing a substantial classing mechanism. Most of the object-like uses of C I've seen haven't had any support for class relationships; those that have have been language implementations. ;) Making this a separate module makes a lot of sense as way to avoid re-engineering at a later point. > For quite a while, I have been passing function pointers around as > CObjects in the modules (eg. gtk._gtk._PyGtk_API in the 0.7.0 release), > which means that the different wrapper modules don't need to see each > other's symbols. Excellent! The example of using a CObject as an API container/ accessor made this look very tedious for the implementor; what can I do to make this easier to use? > As for symbols from libraries, I think from python 1.5.2, it doesn't use > the RTLD_GLOBAL flag when loading extensions, so the extensions don't > pollute the global symbol table. Yes, I understand why, I just recall having lots of problems with the Imlib stuff because of that. That was a year ago, so has probably been fixed at this point, but I must admit that I've not built any of this stuff for a while now. > What would be nice would be if ExtensionClass integrated better with > python (so that all the special cases for normal classes work for > ExtensionClasses). I'd be very interested in your comments on what it would take to make things easier if something like ExtensionClass were available as part of the core, both from the requirements side and ease-of-use perspective. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] gtk-1.3 bindings
On Mon, 26 Jun 2000, Fred L. Drake, Jr. wrote: > > James Henstridge writes: > > It provides a non GUI base for objects. I have been wondering about > > whether to put the base gobject support into a separate module or not, and > > whether I should keep it separate from the gtk package (when you import > > gtk, it initialises the GUI). Does this sound like a good idea? > > I like the idea. The real question is how many libraries will be > built with it that don't also require GTK+? I have little idea about > this, especially since I'm largely disconnected with the C-only > world. Well, this is one of those things where we won't know how many useful non gui libraries will use the object model until after the glib/gtk 2.0 release. I have decided to put the GObject wrapper stuff in a separate module just in case. > > > I don't know how many non gui libraries will be using gobject, and how > > many of those will be useful to python programmers. If we want to wrap > > those libraries and not require gtk be loaded, it will have to be compiled > > as a separate module. > > Overall, it's probably best to assume that at least some interesting > libraries will be built, especially if "interesting" includes "we have > to support X because Y is interesting and requires X objects". I > think the biggest problem we'll have to deal with is the addition of > symbols from libraries required by extension modules to the global > symbol table; I've not played with enough of the recent code to know > if that's still a big problem. I'll try and spend a little time on it > in about three weeks (I'm waiting for a motherboard for my machine > before I can do much on Unix ;( ). For quite a while, I have been passing function pointers around as CObjects in the modules (eg. gtk._gtk._PyGtk_API in the 0.7.0 release), which means that the different wrapper modules don't need to see each other's symbols. As for symbols from libraries, I think from python 1.5.2, it doesn't use the RTLD_GLOBAL flag when loading extensions, so the extensions don't pollute the global symbol table. What would be nice would be if ExtensionClass integrated better with python (so that all the special cases for normal classes work for ExtensionClasses). > > -Fred > James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] gtk-1.3 bindings
James Henstridge writes: > It provides a non GUI base for objects. I have been wondering about > whether to put the base gobject support into a separate module or not, and > whether I should keep it separate from the gtk package (when you import > gtk, it initialises the GUI). Does this sound like a good idea? I like the idea. The real question is how many libraries will be built with it that don't also require GTK+? I have little idea about this, especially since I'm largely disconnected with the C-only world. > I don't know how many non gui libraries will be using gobject, and how > many of those will be useful to python programmers. If we want to wrap > those libraries and not require gtk be loaded, it will have to be compiled > as a separate module. Overall, it's probably best to assume that at least some interesting libraries will be built, especially if "interesting" includes "we have to support X because Y is interesting and requires X objects". I think the biggest problem we'll have to deal with is the addition of symbols from libraries required by extension modules to the global symbol table; I've not played with enough of the recent code to know if that's still a big problem. I'll try and spend a little time on it in about three weeks (I'm waiting for a motherboard for my machine before I can do much on Unix ;( ). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] gtk-1.3 bindings
I just got the HEAD branch of gtk+ compiled on my system, so was thinking of starting off binding it. One of the new features is the GObject system, which is what the GtkObject stuff is based on in gtk+-1.3. It provides a non GUI base for objects. I have been wondering about whether to put the base gobject support into a separate module or not, and whether I should keep it separate from the gtk package (when you import gtk, it initialises the GUI). Does this sound like a good idea? I don't know how many non gui libraries will be using gobject, and how many of those will be useful to python programmers. If we want to wrap those libraries and not require gtk be loaded, it will have to be compiled as a separate module. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
