Python 2.5.1 (r251:54863, May  2 2007, 16:56:35) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 'asd'.find('s', None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__
method
>>> 'asd'.rfind('s', None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__
method
>>> # Note that this works, at the price of a memory copy,
>>> # and on large strings that is undesirable.
>>> 'asd'[None:None].find('s')
1
>>> 'asd'[None:None].rfind('s')
1
>>>

I believe this is because string_find_internal() uses an O& with
_PyEval_SliceIndex() to convert its start and end arguments, but the
latter function does not accept None.  To fix this, you'd have to change
string_find_internal() to do its own argument checking for None before
calling _PyEval_SliceIndex.

Documentation for find():

str.find(sub[, start[, end]])
    Return the lowest index in the string where substring sub is found,
such that sub is contained in the range [start, end]. Optional arguments
start and end are interpreted as in slice notation. Return -1 if sub is
not found.

I think that it shouldn't be possible to call it with None arguments. 

The error message is wrong: it's a TypeError, but the message should say
something like...

  TypeError: slice indices must be integers or have an __index__ method

If you're ok with this change, assign this bug to me and I'll fix it.

Regards,

> The error message is wrong: it's a TypeError, but the message should say
> something like...
> 
>   TypeError: slice indices must be integers or have an __index__ method

This would be a false message, as, as my report demonstrated, slice
indices *can* be None. And there is a very good reason for accepting
None in the second parameter in slice notation as there is no value for
'-0' to represent the end of the region being sliced, and None meaning
'default' fills that need most effectively.

Surely the right fix is as Barry noted, to handle None correctly within
this function?

I also hit this bug. The .index() methods have the same issue,
as well as the methods in the string and strop modules:

>>> "123".index("2", None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
>> import strop, string
>>> strop.rfind("123", "2", None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required
>>> string.rfind("123", "2", None)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/string.py", line 374, in rfind
    return s.rfind(*args)
TypeError: slice indices must be integers or None
>>>

Created the patch, also send a mail to python-dev to see if somebody
wants to review it before me applying it.

facundo, robert and i looked at this patch and it seems okay. 
suggestions: document the reference count semantics of
_ParseTupleFinds() and include a definition of that function in a .h
file.  since its non-public, maybe find.h is the right place to put it?

there also some random addition of trailing whitespace in the last hunk
of stringobject.c

Moved the function to find.h, cleaned the whitespace issues and
documented the reference counting.

Commited in trunk, rev 59020.

Thanks everybody!