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

[Robert Kern]

Bryan Olson wrote:
> Robert Kern wrote:

>  >   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.

len() cannot be used to determine the value of $ in the context of
multiple dimensions.

> 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.

What it does do is provide a second way to do indexing from the end that
can't be extended to multiple dimensions.

> 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.

How? You haven't proposed how an object gets the information that
$-syntax is being used. You've proposed a syntax and some semantics; you
also need to flesh out the pragmatics.

> 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.

I have serious doubts about __len__() returning anything but a bona-fide
integer. We shouldn't need to use incredible hacks like that to support
a core language feature.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter