[Pyrex] Sequence patches from Paul Prescod

[Jim Kleckner]

Robert Bradshaw wrote:
> Interesting. I assume one declares a sequence as
> 
> cdef sequence my_list
> 
> I don't see PySequence_Check being used, I assume it is up to the  
> developer to only assign list/tuple/sequence-supporting objects to  
> such declared variables? It looks like PySequence_GetItem does  
> perform a check though.
> 
> In our SageX fork, we've implemented a runtime check for all indexing  
> (with respect to a c int) and if it is a list/tuple with a valid  
> index, the macro form is called. The checks are all macros too, so  
> when indexing into a list or tuple (by far the most common case, at  
> least in our codebase) we avoid any function calls (let alone the  
> almost a dozen required for boxing an integer and using the generic  
> PyObject_GetItem). It is much, much faster.
> 
> A similar trick is used in for loops and list comprehensions. You can  
> look at it at http://sagemath.org/packages/standard/ (spkg is just a  
> bzipped tar file)

This is very very nice!

Searching the Pyrex email list reveals minimal discussion about
sagex previously (gathered here for convenience):
  http://tinyurl.com/2dr7xh
and it appears that William Stein got no reply to the question about
what to do with sagex wrt pyrex.

I'm very much a newbie to this discussion but my 2 cents is that
your enhancements to Pyrex are extremely attractive.

Greg, would you mind participating in the discussion about possibly
moving Pyrex to sourceforge and using subversion to track it?
Subversion would permit the sagex people to have their own fork
and to merge changes back to the trunk when acceptable to you.


> On Jun 4, 2007, at 1:57 PM, Jim Kleckner wrote:
> 
>> Looking at Pyrex-generated code, I see boxing of integer
>> types when indexing into sequence types that seems avoidable.
>>
>> After digging, I noticed Paul Prescod's patches for sequences
>> that are documented here:
>>
>>  http://www.prescod.net/python/pyrexopt/pyrex_sequences.diff
>>
>> What was the status of this discussion?  It seems like a
>> relatively clean patch.  Is there some reason I should avoid it?