[Python-Dev] Dafanging the find() gotcha
Eric S Raymond
Mon, 5 Aug 2002 17:38:09 -0400
Guido van Rossum <firstname.lastname@example.org>:
> 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.
I understand. But there is a difference between changes that seem likely to
silently break a lot iof things and changes for which one almost has to
contrive an example that would break. I think this one is in the latter
> 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.
Also agreed; I parallel your reasoning as well is your conclusion, and
in fact thought this issue through before before I raised the possibility
> 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.
Yes. Best for things to fail noisily if they're going to fail.
> 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.
This doesn't concern me, and I used to be a mathematical logician
myself. Don't worry about my ex-colleagues -- you're designing a tool
for programming, not a formalism for doing proof theory.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>