| msg56332 - (view) |
Author: Robert Collins (rbcollins) *  |
Date: 2007-10-10 23:41 |
| 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 "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method >>> 'asd'.rfind('s', None, None) Traceback (most recent call last): File "", line 1, in 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 >>> |
|
|
| msg56333 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2007-10-11 01:24 |
| 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. |
|
|
| msg56485 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2007-10-16 02:27 |
| 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, |
|
|
| msg56489 - (view) |
Author: Robert Collins (rbcollins) * |
Date: 2007-10-16 03:59 |
| > 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? |
|
|
| msg56498 - (view) |
Author: Bastian Kleineidam (calvin) |
Date: 2007-10-16 12:45 |
| 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 "", 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 "", line 1, in ? TypeError: an integer is required >>> string.rfind("123", "2", None) Traceback (most recent call last): File "", 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 >>> |
|
|
| msg57024 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2007-11-01 18:08 |
| Created the patch, also send a mail to python-dev to see if somebody wants to review it before me applying it. |
|
|
| msg57043 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2007-11-02 01:09 |
| 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 |
|
|
| msg57587 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2007-11-16 18:06 |
| Moved the function to find.h, cleaned the whitespace issues and documented the reference counting. Commited in trunk, rev 59020. Thanks everybody! |
|
|