Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type
bokr at oz.net
Tue Aug 30 21:17:41 CEST 2005
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
>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.
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.,
would call arr.__getitem__((slice(1,-1,None,STOP), slice(-5,-2,None,START|STOP))
(Hypothesizing bitmask constants START and STOP)
More information about the Python-list