[Python-Dev] None as slice params to list.index() and tuple.index()
Guido van Rossum
guido at python.org
Tue Nov 8 09:41:42 CET 2011
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.
On Sun, Nov 6, 2011 at 11:56 AM, Raymond Hettinger
<raymond.hettinger at 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.
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev