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

[Bengt Richter]

On Tue, 30 Aug 2005 11:56:24 GMT, Bryan Olson <fakeaddress at nowhere.org> wrote:

>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.
>
>
(OTTOMH ;-)
Perhaps the slice triple could be extended with a flag indicating
which of the other elements should have $ added to it, and $ would
take meaning from the subarray being indexed, not the whole. E.g.,

    arr.[1:$-1, $-5:$-2]

would call arr.__getitem__((slice(1,-1,None,STOP), slice(-5,-2,None,START|STOP))

(Hypothesizing bitmask constants START and STOP)

Regards,
Bengt Richter