George King added the comment:
I think it is a mistake not to support None values. Please consider:
The existing message clearly suggests that the intent is to support the same
set of values as the start/stop parameters of the slice type. str, bytes, and
bytearray all support None for `index`, as well as `count`, `find`, `rfind`,
and `rindex`.
Not supporting None makes the type signature of list.index and tuple.index
subtly different from those of str, bytes, and bytearray, when they could
otherwise be interchangeable. It makes the type signature of index inconsistent
across the types.
Furthermore, it makes converting slice start/stop to these arguments a pain.
Compare the following:
seq.index(start=slice.start, end=slice.stop) # accepting None
seq.index(start=(0 if slice.start is None else slice.start), end=(len(seq)
if slice.stop is None else slice.stop)) # current behavior.
I do not buy the argument that the latter communicates intent better, and it is
adds bug-prone baggage to every call site.
Similarly, being able to pass None for end/stop parameters is very convenient
in the case of optional passthrough arguments, saving the programmer from this:
def f(seq, end=None):
i = seq.index(start=0, end=(len(seq) if end is None else end)) # current
behavior.
...
Note that for the programmer writing `f`, None (or some other distinct sentinel
value) is a *requirement* for correctness, because end=len(seq) is incorrect.
I would understand opposition to this on the basis of not changing existing
behavior in any way, but "communicating intent" seems like a thin argument in
comparison to the above.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue29935>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
