Optimized the inner loop for iterobjects resulting in 
a 19% speed-up for tuples and a 15% improvement for 
strings and xrange objects.  Dictionaries and lists 
are unaffected (already handled as a special case or 
with their own iterators).

1. Replaced PyList_Check with PyList_CheckExact.  
Loses the special case handling for list subtypes but 
gains speed because PyList_Check called the slow 
function, PyType_IsSubtype.

2. Added special case handling for tuples.  Identical 
to the existing special case for lists (calls ob_size 
and ob->item[i] directly).

3. Replaced the call to PySequence_GetItem function 
with a macro for direct access to the sequence's 
sq_item slot.  Saves a function call, unnecessary 
(previously checked) checks for tp_as_sequence and 
sq_item, and an unnecessary check for negative indices 
(sq_item has its own checks).

This small patch speeds-up looping throughout Python 
whether it is called through list(seq), a for-loop, or 
a functional.

Logged In: YES 
user_id=21627

The patch looks good, but needs some minor corrections:

Returning NULL in response to a failed _Check is incorrect -
no exception is set at that point.

I think the addition of PySequence_ITEM needs to be
mentioned in the documentation and Misc/NEWS.

Logged In: YES 
user_id=80475

Done.

Added news and docs.

Instead of raising an exception, converted PySequence_Check 
to an assertion because it is a pre-condition of the 
function and has already been checked by PyObject_GetIter.  
The only way for the assertion to fail is if an extension 
writer by-passes _GetIter and directly calls PySeqIter_New 
with a non-sequence argument.

Logged In: YES 
user_id=21627

I'm not sure what the convention for assertions is; the
alternative is to raise BadInternalCall.

If I would have to define a convention, it would go like
this: If this can be called incorrectly by extension
modules, it's a bad internal call; if the only callers would
be the core, it's an assert. It is also an assert if you can
prove that it can never occur with the current code base.

Logged In: YES 
user_id=80475

Agreed.  Replaced assertion with BadInternalCall.

Logged In: YES 
user_id=21627

It appears that this code might still return NULL without
setting an exception, if it_index is larger then the size.

Logged In: YES 
user_id=80475

This is the current and documented behavior of the next 
routine for iterobjects.  From the docs, "If the object is 
an iterator, this retrieves the next value from the 
iteration, and returns NULL with no exception set if there 
are no remaining items".

Also, note the existing special case for lists has 
identical coding and behavior.  

Also, compare to the code fragment below it, for the 
general case, which explicitly calls PyErr_Clear() and then 
returns NULL.

IOW, I believe the code is correct as it stands and is 
ready to be loaded to CVS.

Logged In: YES 
user_id=21627

Thanks for the patch; applied as

iterobject.c 1.9
NEWS 1.404
abstract.h 2.44
abstract.tex 1.14