This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: list and tuple index methods should accept None parameters
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.7, Python 3.6, Python 3.5, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: JelleZijlstra, gwk, rhettinger, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-03-28 16:16 by gwk, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 887 merged serhiy.storchaka, 2017-03-29 16:42
PR 907 merged serhiy.storchaka, 2017-03-30 16:08
PR 909 merged serhiy.storchaka, 2017-03-30 17:01
PR 910 merged serhiy.storchaka, 2017-03-30 17:01
Messages (11)
msg290737 - (view) Author: George King (gwk) * Date: 2017-03-28 16:16
As of python3.6, passing None to the start/end parameters of `list.index` and `tuple.index` raises the following exception:
"slice indices must be integers or None or have an __index__ method"

This suggests that the intent is to support None as a valid input. This would be quite useful for the end parameter, where the sensible default is len(self) rather than a constant. Note also that str, bytes, and bytearray all support None.

I suggest that CPython be patched to support None for start/end. Otherwise, at the very least the exception message should be changed.

Accepting None will make the optional start/end parameters for this method more consistent across the types, which is especially helpful when using type annotations / checking.
msg290783 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-03-29 16:02
The error message should be fixed and the API should be left alone.  A *None* value doesn't do a good jog of communicating intent.
msg290786 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-29 16:46
I concur with Raymond. Proposed patch fixes error messages and doesn't change the public API.
msg290788 - (view) Author: George King (gwk) * Date: 2017-03-29 17:57
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.
msg290822 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2017-03-30 06:28
I agree with George that supporting None here is the better option.

This problem also applies to collections.deque. tuple, list, and deque all have very similar index implementations, and it would be nice to merge their argument parsing boilerplate.
msg290838 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-03-30 09:12
Sorry, modifying these mature APIs is a really bad idea.  They are worked well as-is of over a decade.  Seeing people use None for these arguments makes the code less readable. 

Python has a number of APIs where the number of arguments controls the behavior.  For example, type() with one argument does something very different that type() with three arguments.  Likewise, iter() behaves differently with two arguments than three.  The pattern used by index() shows-up in a number of places where we have optional start and end arguments.  These APIs are a long standing Python norm, both for the core and for third-party modules.  Type checking will have to adapt to norms rather than having all of Python change for the convenience of typing.

Serhiy, please go ahead with the doc fix.

If the OP really wants to insist on changing old and stable APIs through out the language in a way that I consider harmful to readability, we can battle it out in a PEP and on mailing lists.
msg290851 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-30 15:21
Thank you Raymond for your review.

In any case we should first fix error messages in maintain releases. Changing signatures of methods of basic type should be discussed on the mailing lists. I don't think this needs a PEP, unless this change will be extended to many other methods and types.
msg290853 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-30 15:29
New changeset d4edfc9abffca965e76ebc5957a92031a4d6c4d4 by Serhiy Storchaka in branch 'master':
bpo-29935: Fixed error messages in the index() method of tuple, list and deque (#887)
https://github.com/python/cpython/commit/d4edfc9abffca965e76ebc5957a92031a4d6c4d4
msg290860 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-30 16:47
New changeset bf4bb2e43030661e568d5d4b046e8b9351cc164c by Serhiy Storchaka in branch '3.6':
bpo-29935: Fixed error messages in the index() method of tuple, list and deque (#887) (#907)
https://github.com/python/cpython/commit/bf4bb2e43030661e568d5d4b046e8b9351cc164c
msg290864 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-30 17:31
New changeset 8b8bde44f3912d8b2df5591ffc31d2d8c6dcca6c by Serhiy Storchaka in branch '3.5':
bpo-29935: Fixed error messages in the index() method of tuple, list and deque (#887) (#907) (#909)
https://github.com/python/cpython/commit/8b8bde44f3912d8b2df5591ffc31d2d8c6dcca6c
msg290865 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-30 17:32
New changeset 079f21f873b99f9564a41c5b7f3e0d7035847ae5 by Serhiy Storchaka in branch '2.7':
bpo-29935: Fixed error messages in the index() method of tuple and list (#887) (#907) (#910)
https://github.com/python/cpython/commit/079f21f873b99f9564a41c5b7f3e0d7035847ae5
History
Date User Action Args
2022-04-11 14:58:44adminsetgithub: 74121
2017-03-30 17:34:56serhiy.storchakasetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2017-03-30 17:32:19serhiy.storchakasetmessages: + msg290865
2017-03-30 17:31:48serhiy.storchakasetmessages: + msg290864
2017-03-30 17:01:40serhiy.storchakasetpull_requests: + pull_request810
2017-03-30 17:01:01serhiy.storchakasetpull_requests: + pull_request809
2017-03-30 16:47:02serhiy.storchakasetmessages: + msg290860
2017-03-30 16:08:21serhiy.storchakasetpull_requests: + pull_request807
2017-03-30 15:29:26serhiy.storchakasetmessages: + msg290853
2017-03-30 15:21:39serhiy.storchakasetmessages: + msg290851
2017-03-30 09:12:24rhettingersetmessages: + msg290838
2017-03-30 06:28:20JelleZijlstrasetnosy: + JelleZijlstra
messages: + msg290822
2017-03-29 17:57:09gwksetmessages: + msg290788
2017-03-29 16:46:00serhiy.storchakasettype: enhancement -> behavior
stage: patch review
messages: + msg290786
versions: + Python 2.7, Python 3.5, Python 3.6
2017-03-29 16:42:58serhiy.storchakasetpull_requests: + pull_request789
2017-03-29 16:02:01rhettingersetnosy: + rhettinger
messages: + msg290783
2017-03-28 17:39:10serhiy.storchakasetassignee: serhiy.storchaka

nosy: + serhiy.storchaka
2017-03-28 16:35:11gwksettype: enhancement
2017-03-28 16:33:40Jim Fasarakis-Hilliardsetcomponents: + Interpreter Core
versions: + Python 3.7
2017-03-28 16:16:21gwkcreate