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.