[Python-Dev] Dafanging the find() gotcha

[Andrew Koenig]

Tim> The question for you is, *however* the value of s was obtained,
Tim> if you end up doing "s in t" when s happens to be an empty
Tim> string, is it more likely that your program has strayed from your
Tim> intent, or that a result of True *was* your intent?

It isn't *the* question; it's *a* question.

Another question is whether adding additional complexity to the rules
helps or hurts in genera.

Tim>     if s[j+k1:j+k2] in t:

Tim> Assuming type correctness, if I know that raises an exception whenever k1 >=
Tim> k2, then I have confidence I know what the code is trying to do, and rest
Tim> easy knowing it won't do something nuts if the index expressions go crazy.
Tim> If instead it never(!) raises an exception, no matter what the values of j,
Tim> k1 and k2, this code scares me.

Then why not remove your fear by executing

        assert k1 < k2

first?

Tim> When Python switched to allowing negative indices as sequence
Tim> subscripts (it didn't always -- they used to raise exceptions),
Tim> it introduced a nasty class of bug caused by conceptually
Tim> non-negative indices going negative by mistake, but no longer
Tim> complaining.  Overall I think negative indices added enough
Tim> expressiveness to outweigh that drawback, but it was far from a
Tim> pure win.  This is a case where we're also keen to make a
Tim> formerly exceptional operation "mean something", but there's one
Tim> particular case of it where I know doing so will create similar
Tim> new problems -- and it's a case that's of no *real* use to allow.

Well, we don't know that yet.  We just know that you haven't seen one.
And I must say that I don't expect (s1 in s2) to be all that common
an operation anyway when s1 and s2 are strings.

>> And it says even less about why it would be a good idea to have
>> the result of such a search yield different results in different
>> contexts.

Tim> I agree that's not a good thing at all, and it may well win Guido
Tim> in the end.  I just hope he feels rotten about it, because the
Tim> children will suffer as a result <wink>.

This whole issue feels to me like the way APL behaves when you ask it
for the number of elements in a scalar:  Instead of giving the obvious
answer (a scalar has 1 element), it gives a much deeper answer (the
number of elements in a scalar is an empty vector, because a scalar
has no dimensions).  That behavior bites novices all the time, but
I have encountered programs that become much simpler as a result.

-- 
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark