Repository navigation
Support None as start/stop index? #138134
Description
None is accepted as start and stop index in slices. a[None:i] is equivalent to a[:i] and a[i:None] is equivalent to a[i:], independently from the type of the sequence. It is also accepted as the start or end index in the str, bytes and bytesrray methods index(), count(), startswith() and endswith(). This is not documented and officially supported feature. The documentation contains something like index(value[, start[, end]]), pydoc shows this as well, and inspect.signature() fails for these methods
The start and end indices in the tuple, list, memoryview, array and deque method index() only accept integers (including negative values). It was previously discussed in
- list.index does not accept None as start or stop #57549
- list and tuple index methods should accept None parameters #74121
and support of None was even merged, but then reverted.
Sequence.index() supports None since #67275 (although it seems there is a bug for start=None).
This inconsistency is just an annoying nuisance, except that it is difficult to express the default value for the stop index. For in-memory collections we can use sys.maxsize, but currently inspect and pydoc show it as a huge integer value:
>>> inspect.signature(tuple.index)
<Signature (self, value, start=0, stop=9223372036854775807, /)>I think this is an argument to support None as the stop index (and as the start index for consistency). The possible drawback is that when None was the result of error, this error will no longer be detected.
For now, there were two open ways:
- Declare official support of
Nonein methods which support it de-facto.inspect.signature()will support this. Also, add support ofNonein theindex()methods of other classes (this is very easy now). - Deprecate support of
Nonein methods which support it. This was perhaps an unintentional effect of using a particular private C API. We need support of multisignatures in theinspectandpydocmodules to get and show adequate signatures, but we need this fortuple.index()etc:(value, start=0, /) (value, start, stop, /)
cc @rhettinger
Activity
picnixz commentedon Aug 25, 2025
To understand the issue:
Sequence.indexis meant to support None.Nonein their index() method.Nonein their index() method.We have two plans:
Sequence.indeximplementations supportNone.If we do 2), shouldn't we also revert
Sequence.indexsupporting None? AFAIK, the examples in https://docs.python.org/3/library/collections.abc.html actually don't even show thatSequence.indexmust have 3 arguments despite https://docs.python.org/3/library/collections.abc.html#collections.abc.Sequence indicating thatstartandstopare now supported inindex.The source code however says
Supporting start and stop arguments is optional, but recommended:cpython/Lib/_collections_abc.py
Lines 1047 to 1052 in 7e4afe0
AFAICT, there is no strict guidelines on the meaning of
startandstop(though we're full of incompatible signature violations, e.g., tuple is not a subtype of Sequence in the strict sense as it doesn't accept None forstop). Should we support them to be a sequence or not?Personally, I'm in favor of supporting None because it could simplify the rendered signature and makes it simpler to use. However, one could argue that for
stopit doesn't matter because it's the last parameter, so whether we writex.index(i, None)orx.index(i, sys.maxsize), both can simply bex.index(i). What's interesting however is that it allows consumers to be simplified as they won't need to handle a None end themselves (and they could avoid using a default beingsys.maxsizefor instance).serhiy-storchaka commentedon Aug 25, 2025
Note that support of start/stop arguments in
Sequence.index()is recent change and it was breaking. Not all sequences support them, and very few of them support them as keyword arguments.Adding support of
Noneis very easy in CPython code. It is a little more in user code, but I do not propose to force this, and it is dwarfed by the need to support negative and out of range values.AA-Turner commentedon Aug 25, 2025
I think I prefer option 2 (do not support None). It is supported in the
[...]methods I believe as a result ofslice(...), but for the various methodsNonehas unclear intent, and as you say could hide an error with an unexpectedNonevalue.I think it would be better to advance multisignature support than use
Noneas a 'nice' default. We could also revisitinspect.UNREPRESENTABLEas a stop-gap forhelp/pydocoutput, instead of changing the runtime behaviour.A
serhiy-storchaka commentedon Feb 20, 2026
Other discussion (opened 1.5 years before this issue): https://discuss.python.org/t/none-as-index/50825/