Nick Coghlan wrote:
> Travis Oliphant wrote:
>>> Probably the most interesting thing now would be for Travis to review
>>> it, and see whether it makes things easier to handle for the Numeric
>>> scalar types (given the amount of code the patch deleted from the
>>> builtin and standard library data types, hopefully the benefits to
>>> Numeric will be comparable).
>>
>> I noticed most of the checks for PyInt where removed in the patch. If I
>> remember correctly, I left these in for "optimization." Other than
>> that, I think the patch is great.
>
> You're right - there was a fast path based on PyInt_Check in
> _PyEval_SliceIndex that got lost, which I'll add back in. I'll also add fast
> paths for PyInt_Check to the functions in abstract.c, too.
>
> The other PyInt_Check's (in slot_nb_index and instance_index) were there to
> check that __index__ returned the right thing. The check was still there in
> slot_nb_index, but I'd incorrectly removed it from instance_index. I'll add
> that one back in, too.
>
> Once that's done, I'll update the tracker item and reassign to Tim for a
> review.
Aside from the 'assign to Tim' part, this is done now (pep357-fix-v3 on the
tracker item). I also tweaked the clipping version of the C API to optionally
expose the overflow flag that abstract.c was using internally so the client
code can find out whether or not clipping actually occurred.
The patch also updates the index unit tests to:
- cover the various type errors that Travis picked up
- actually run the full set of unit tests under -O
- only run the basic sequence independent tests once (instead of once per
sequence type)
Neal also had a number of questions that I responded to in the tracker comments.
The most significant question related to the API signature, which Neal
considered potentially confusing:
PyNumber_Index(PyObject *item, int *is_index)
I added the is_index flag to the function signatures instead of providing a
separate PyNumber_IndexCheck function in order to avoid doing the same type
check twice in the typical mp_subscript implementation cases.
One possibility would be to invert the sense of that flag and call it
"typeerror", which probably more accurately reflects what it's intended for -
it's a way of telling the function "if this object does not have the correct
type, tell me by setting this flag instead of by setting the Python error
state".
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
