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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4