-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
list and tuple index methods should accept None parameters #74121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
As of python3.6, passing None to the start/end parameters of 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. |
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. |
I concur with Raymond. Proposed patch fixes error messages and doesn't change the public API. |
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 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
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: Note that for the programmer writing 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. |
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. |
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. |
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: