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 consiste
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 b
On Mon, Nov 7, 2011 at 8:16 AM, Antoine Pitrou 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 Sun, 6 Nov 2011 09:49:27 +0200
Petri Lehtinen 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 "", line
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 "", line 1, in
TypeError: slice indices must be integers or None or have an __
