Though I haven't quite seen it said explicitly -- is this proposed to be added to the Sequence ABC?
If so, there is a potential problem -- the ABC's "namespace" is not reserved, so if you add .get(), then any code out in the while that is already using .get in a custom sequence could potentially break.
See the discussion about the idea of adding a .view() method to Sequences -- same issue. Even of you think it's a good idea, it's still hard to add a new (non-dunder) method to an ABC.
I think if it's a potential problem to add it to the ABC then let's just defer that and only add it to the built in sequences.
But I'm not clear on what the problem is. If you have some code like this:
```
class MySequence(Sequence):
def get(self, i): ...
MySequence().get(3)
```
and then add .get to the Sequence ABC, the existing code will not be immediately broken because the custom MySequence.get overrides the ABC method so everything behaves as before.
A problem that I can see eventually arising is if someone writes some generic code for Sequences using .get, MySequence won't work with it. That won't happen immediately and I'm not sure if I'd call it a break in compatibility. But I can see that it is a problem.
Maybe if we build up enough methods to add to the collection ABCs (Sequence.view, Sequence.get, Set.intersection/union/etc, Mapping.__[i]or__) we can justify adding them all at once in Python 4 or in a new module collections.abc.v2 which has subclasses of the originals.