> > Eric> Raise an exception. Definitely. There is no reason to follow
> > Eric> find() rigidly when the whole point is to have semantics
> > Eric> different from find(). Besides, you're right to point out that
> > Eric> changing this behavior could break existing code, and that is a
> > Eric> big no-no.
> Andrew Koenig <ark@research.att.com>:
> > Changing the meaning of ('ab' in 'abc') might also break existing code.
> I could construct a try/except case that would change, yes. Are you
> being pedantic, or is this intended as a serious objection?
Andrew appears to say that if you object against '' in 'abc' not
raising an exception, you should also object against the other one;
but his real point is the corollary: since you don't object against
giving 'ab' in 'abc' new meaning, you shouldn't object against a new
meaning for '' in 'abc' either -- at least not based on the argument
of breaking code. Whenever we say that a change doesn't break code,
we almost always imply "except code that depends on a particular thing
raising an exception".
That '' in 'abc' or 'ab' in 'abc' raises TypeError tells me that it is
okay to change this behavior into doing something useful, *if* we have
a useful thing to substitute for the exception.
Tim is arguing that '' in 'abc' is not a useful question to ask. The
usefulness of the exception is not that it's a feature on which
correct programs depend, but that it's an early warning that your
program is broken. Losing that early warning sign would mean more
time wasted debugging.
OTOH I'm worried that some code doing some mathematical proof using
substring relationships would find it irritating to have to work
around the irregularity. But I admit that this is a purely
theoretical fear for now.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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