All, please decide without me. On 8/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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/guido%40python.org >
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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