None as slice params to list.index() and tuple.index()
list.index() and list.tuple() don't currently accept None as slice parameters, as reported in http://bugs.python.org/issue13340. For example:
[1, 2, 3].index(2, 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
The error message of list.index() and tuple.index() (as a consequence of using _PyEval_SliceIndex() for parsing arguments) indicates that None is a valid value. Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too? I'm bringing this up because I already committed a fix that enables the None arguments, but Raymond pointed out that maybe they shouldn't accept None at all. I also committed the fix to 3.2 and 2.7 based on discussion in http://bugs.python.org/issue11828#msg133532, in which Raymond says that for string functions, this can be considered a bug because the exception's error message makes a promise that None is accepted. Petri
On Sun, 6 Nov 2011 09:49:27 +0200 Petri Lehtinen <petri@digip.org> wrote:
list.index() and list.tuple() don't currently accept None as slice parameters, as reported in http://bugs.python.org/issue13340. For example:
[1, 2, 3].index(2, 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
The error message of list.index() and tuple.index() (as a consequence of using _PyEval_SliceIndex() for parsing arguments) indicates that None is a valid value.
Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too?
Either that or fix the error message. I can't find much benefit in accepting None, that said (nor in refusing it). Regards Antoine.
On Mon, Nov 7, 2011 at 8:16 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Either that or fix the error message. I can't find much benefit in accepting None, that said (nor in refusing it).
Its very convenient when working with slices to not have to special case the end points. +1 on accepting None, FWIW. -Rob
On Nov 6, 2011, at 12:49 AM, Petri Lehtinen wrote:
Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too?
The string methods accept None as a historical artifact of being in string.py where optional arguments defaulted to None. That doesn't imply that you should change every other API that accepts a start argument. The list.index() API is ancient and stable. There has been little or no demonstrated need for its start argument to be None. Also, the list API does not exist in isolation. It shows up in strings, the sequence ABC, and every API that aspires to be list-like. Overall, I'm -1 on this change and find it to be gratuitous. We have *way* to many micro API changes of dubious benefit. Also, the change should not have been applied to Py2.7 and Py3.2. We don't backport API changes. That would just make Jython and IronPython become non-compliant in mid-stream. Raymond
Hm. I agree with Raymond that this should be treated as a feature request and not "fixed" in 2.7 / 3.2. (However the mention of 'find' in the error message for 'index' is a bug and should be fixed.) As for the feature request, I think that allowing None in more places is more regular and consistent across interfaces. I note that the slice() object also represents "missing" or "default" values as None, so it is not just a carryover from the old string.py. So, +1 on the feature for 3.3; -1 on the "fix" in 3.2 or 2.7. --Guido On Sun, Nov 6, 2011 at 11:56 AM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Nov 6, 2011, at 12:49 AM, Petri Lehtinen wrote:
Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too?
The string methods accept None as a historical artifact of being in string.py where optional arguments defaulted to None. That doesn't imply that you should change every other API that accepts a start argument. The list.index() API is ancient and stable. There has been little or no demonstrated need for its start argument to be None. Also, the list API does not exist in isolation. It shows up in strings, the sequence ABC, and every API that aspires to be list-like. Overall, I'm -1 on this change and find it to be gratuitous. We have *way* to many micro API changes of dubious benefit. Also, the change should not have been applied to Py2.7 and Py3.2. We don't backport API changes. That would just make Jython and IronPython become non-compliant in mid-stream.
Raymond
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
participants (5)
-
Antoine Pitrou -
Guido van Rossum -
Petri Lehtinen -
Raymond Hettinger -
Robert Collins