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
