Add SimpleSequence as preferred alias for SupportsLenAndGetItem

[srittau]

This protocol represents a sequence as defined in the Python
documentation, as opposed to collections.abc.Sequence.

[srittau]

Maybe we can find a better name? But it should have Sequence in there.

[Akuli]

I think the name should be super obvious, so that you immediately know what it does when you see it somewhere in the code, such as SupportsLenAndGetItem :)

[srittau]

There already is a concept in Python that expresses this, "sequence". We should use this name to make it clear that this protocol actually reflect that concept.

[Akuli]

What about functions that only require the sequence to have a __getitem__ method, such as iter()? There is no one single type that describes "what you actually want to use when it's tempting to use Sequence", as that may or may not require __len__ to exist, so I don't think we should make a protocol whose name suggest that it is "what you actually want to use when it's tempting to use Sequence".

[Akuli]

Actually nevermind. A type like "what docs describe as Sequence" is fine, because it is very uncommon to implement __getitem__ without __len__, so I don't think this will be a problem in practice. And in many cases, SupportsLenAndGetItem is an improvement over Sequence.

As a side note, I generally consider Sequence a bit of a code smell, because often the reality is "the code for loops over it" or "the code checks for lists and tuples with isinstance".

[Akuli]

I intended to include this in my other review, but I think I clicked the wrong button.

Edit: Now my first review comment was lost somehow, I'll just write it here instead of trying to add another review and losing something again :) The new name should say "it is sequence the concept, not the class" or "it has __len__ and __getitem__". So something like SequenceAccordingToDocs, but that isn't a great name either.

[Akuli]

Why not just delete it? It was not marked with # stable.

[hauntsaninja]

I guess if it's used in third party stubs (there seems to be the one single case), under some circumstances you could run into silent loss of type checking. This already ends up happening though, e.g. see #5786 and #5751, so I'd also be inclined to just delete it.

If we don't delete it, we should alias here, though, and still update the annoy stubs

[srittau]

The annoy stubs were my main concern. If we update them, they won't work, until type checkers have been updated with the latest typeshed. I'd suggest keeping it for a few months.

[hauntsaninja]

I don't feel strongly about this name vs SupportsLenAndGetItem. Typing users I interact with still get confused about just Sequence vs List :-)

[srittau]

Edit: Now my first review comment was lost somehow, I'll just write it here instead of trying to add another review and losing something again :) The new name should say "it is sequence the concept, not the class" or "it has __len__ and __getitem__". So something like SequenceAccordingToDocs, but that isn't a great name either.

PythonSequence, GlossarySequence, NotThatOtherSequence, RealSequence

[Akuli]

As a maintainer, I would love it to be NotThatOtherSequence, but that isn't exactly very contributor friendly because most other people don't know the context.

[Akuli]

How about GetItemAndLenSequence? It seems to satisfy everyone's needs, as it very clearly says what an object must have to satisfy the protocol, and the name also hints that it is an alternative to the usual Sequence. I think it would be an improvement over SupportsLenAndGetItem, because there are mappings that also support __len__ and __getitem__, but the protocol isn't intended to be used with those.

[BvB93]

Yet another option would bo something like PySequence; this is the name used in the C-API to refer to this type of protocol.

[JelleZijlstra]

I don't like PySequence; if a user sees a Sequence and a PySequence, how are they supposed to know which is which?

I'm OK with most other options presented here, but I prefer SimpleSequence for brevity or SupportsGetItemAndLen (the current version) for explicitness.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

bidict (https://github.com/jab/bidict)
- bidict/_base.py:395: error: Argument 1 to "reversed" has incompatible type "MutableMapping[KT, VT]"; expected "SupportsLenAndGetItem[KT]"  [arg-type]
+ bidict/_base.py:395: error: Argument 1 to "reversed" has incompatible type "MutableMapping[KT, VT]"; expected "SimpleSequence[KT]"  [arg-type]

[hauntsaninja]

I don't think we have consensus here, so closing as per #6563 (comment)