[Pyrex] Pyrex optimization

[Phillip J. Eby]

At 09:45 AM 1/14/04 -0800, Paul Prescod wrote:
>Jiba wrote:
>
>>...
>>I have arrived to similar conclusion, and i was wondering if it would be
>>possible to "import" in Pyrex the list and dict classes/types, e.g. from
>>python.h
>
>I don't know precisely what you mean. It is possible to extend the Pyrex 
>code to deal with them but it is a lot more work than an import statement. 
>;) I've started doing this.

It would be really nice if one could declare builtins handling with some 
sort of 'cdef type' extensions, rather than having to build it into the 
Pyrex core.  For getting Pyrex into the Python core, it'd be a lot less 
hassle to add a new e.g. 'sets.pxi' file than it would to hack the Pyrex 
code generator again.  E.g. something like

cdef pytype sequence int PySequence_Check(object):
     __getitem__ = object PySequence_GetItem(object,int)
     __contains__ = int PySequence_In(object,object) except -1
     #... etc.

Obviously, the syntax isn't even quarter-baked, but the idea is that it 
would be nice to define these Python/C "protocols" for Pyrex to use, 
including the function to call to do the type checking.  Thus, when one 
assigns to a  'sequence' parameter or variable, the appropriate check is 
performed.

A similar thing could be done for list, dict, mapping, etc., with the 
ability to use macros for the exact types.

The other performance issues I've seen with Pyrex are attribute access, and 
global names.  I don't know if these are fixed in 0.9, but in previous 
versions, Pyrex uses PyObject_GetAttrString() for attribute lookup, which 
requires memory allocation and various nested calls of overhead before it 
then calls PyObject_GetAttr().  Calling the latter directly should greatly 
improve attribute access speed, as it has when I've manually done the work 
to make it happen in Pyrex.