[Python-Dev] Dafanging the find() gotcha

[Eric S Raymond]

Guido van Rossum <guido@python.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
category.

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

Agreed.

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

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