Can str.find be listed in PEP 3000 (under builtins) for removal?
Would anyone really object?

Reasons:

1. Str.find is essentially redundant with str.index.  The only difference 
is that str.index Pythonically indicates 'not found' by raising an 
exception while str.find does the same by anomalously returning -1.  As 
best as I can remember, this is common for Unix system calls but unique 
among Python builtin functions.  Learning and remembering both is a 
nuisance.

2. As is being discussed in a current c.l.p thread, -1 is a legal indexing 
subscript.  If one uses the return value as a subscript without checking, 
the bug is not caught.  None would be a better return value should find not 
be deleted.

3. Anyone who prefers to test return values instead of catch exceptions can 
write (simplified, without start,end params):

def sfind(string, target):
  try:
    return string.index(target)
  except ValueError:
    return None # or -1 for back compatibility, but None better

This can of course be done for any function/method that indicates input 
errors with exceptions instead of a special return value.  I see no reason 
other than history that this particular method should be doubled.

If .find is scheduled for the dustbin of history, I would be willing to 
suggest doc and docstring changes.  (str.index.__doc__ currently refers to 
str.find.__doc__.  This should be reversed.)

Terry J. Reedy



_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to