Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type

[Bryan Olson]

Robert Kern wrote:
 > Bryan Olson wrote:
 >
 >
 >>     Currently, user-defined classes can implement Python
 >>     subscripting and slicing without implementing Python's len()
 >>     function. In our proposal, the '$' symbol stands for the
 >>     sequence's length, so classes must be able to report their
 >>     length in order for $ to work within their slices and
 >>     indexes.
 >>
 >>     Specifically, to support new-style slicing, a class that
 >>     accepts index or slice arguments to any of:
 >>
 >>         __getitem__
 >>         __setitem__
 >>         __delitem__
 >>         __getslice__
 >>         __setslice__
 >>         __delslice__
 >>
 >>     must also consistently implement:
 >>
 >>         __len__
 >>
 >>     Sane programmers already follow this rule.
 >
 >
 > Incorrect. Some sane programmers have multiple dimensions they need to
 > index.
 >
 >   from Numeric import *
 >   A = array([[0, 1], [2, 3], [4, 5]])
 >   A[$-1, $-1]
 >
 > The result of len(A) has nothing to do with the second $.

I think you have a good observation there, but I'll stand by my
correctness.

My initial post considered re-interpreting tuple arguments, but
I abandoned that alternative after Steven Bethard pointed out
how much code it would break. Modules/classes would remain free
to interpret tuple arguments in any way they wish. I don't think
my proposal breaks any sane existing code.

Going forward, I would advocate that user classes which
implement their own kind of subscripting adopt the '$' syntax,
and interpret it as consistently as possible. For example, they
could respond to __len__() by returning a type that supports the
"Emulating numeric types" methods from the Python Language
Reference 3.3.7, and also allows the class's methods to tell
that it stands for the length of the dimension in question.


-- 
--Bryan