Currently, the Sequence ABC doesn't support start and stop arguments for the index() method which limits its usefulness in doing repeated searches (iterating over a target value) and which limits it substitutablity for various concrete sequences such as tuples, lists, strings, bytes, bytearrays, etc.

>>> help(Sequence.index)
Help on method index in module _abcoll:

index(self, value) unbound _abcoll.Sequence method
    S.index(value) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(list.index)
Help on method_descriptor:

index(...)
    L.index(value, [start, [stop]]) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(str.index)
Help on method_descriptor:

index(...)
    S.index(sub [,start [,end]]) -> int
    
    Like S.find() but raise ValueError when the substring is not found.

>>> help(tuple.index)
Help on method_descriptor:

index(...)
    T.index(value, [start, [stop]]) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(bytes.index)
Help on method_descriptor:

index(...)
    S.index(sub [,start [,end]]) -> int
    
    Like S.find() but raise ValueError when the substring is not found.

>>> help(bytearray.index)
Help on method_descriptor:

index(...)
    B.index(sub [,start [,end]]) -> int
    
    Like B.find() but raise ValueError when the subsection is not found.

A wild patch appears!

Test is included, I'm unhappy with it, because it uses one test method to test all of Sequence, but that's what the test suite does for MutableSequence.

This test looks like it may have been a typo:

   self.assertEqual(seq.index('a'), 0, 1)

Also, it would be nice to investigate the differences with list.index() and str.index() for the corner cases.  Something along these lines:

    # Compare Sequence.index() behavior to list.index() behavior                        
    listseq = list('abracadabra')
    seqseq = SequenceSubclass(listseq)
    for start in range(-3, len(listseq) + 3):
        for stop in range(-3, len(listseq) + 3):
            for letter in set(listseq + ['z']):
                try:
                    expected = listseq.index(letter, start, stop)
                except ValueError:
                    with self.assertRaises(ValueError):
                        seqseq.index(letter, start, stop)
                else:
                    actual = seqseq.index(letter, start, stop)
                    self.assertEqual(actual, expected, (letter, start, stop))

    # Compare Sequence.index() behavior to str.index() behavior                         
    strseq = 'abracadabra'
    seqseq = SequenceSubclass(strseq)
    for start in range(-3, len(strseq) + 3):
        for stop in range(-3, len(strseq) + 3):
            for letter in set(strseq + 'z'):
                try:
                    expected = strseq.index(letter, start, stop)
                except ValueError:
                    with self.assertRaises(ValueError):
                        seqseq.index(letter, start, stop)
                else:
                    actual = seqseq.index(letter, start, stop)
                    self.assertEqual(actual, expected, (letter, start, stop)

I modified your test case somewhat. Also, your tests uncovered an issue with negative indexes -- oops, hadn't thought of those. Fixed. Let me know what you think.

Why is there no "review" link next to my second patch?

Try something like this:

        if start < 0:
            start += len(self)
        if stop is None:
            stop = len(self)
        elif stop < 0:
            stop += len(self)
        for i in range(max(start, 0), min(stop, len(self))):
            if self[i] == value:
                return i
        raise ValueError

Are you sure? I noticed that __iter__ went out of its way to avoid calling len().

I think it avoids len because the length might change during iteration due to side-effects of other code. Since a shrinking sequence would raise an IndexError anyway when you overran the end, it may as well not assume the length is static and just keep indexing forward until it hits an IndexError. It's less of an issue (though not a non-issue) with index, because index actually performs all the indexing without returning to user code; __iter__ pauses to allow user code to execute between each yield, so the odds of a length mutation are much higher.

You might be able to use len (and just say that if a side-effect of an equality comparison causes the sequence to change length, or another thread messes with it, that's your own fault), but you'd probably want  to catch and convert IndexError to ValueError to consistently respond to "we didn't find it" with the same exception.

Note: index returns without the caller having a chance to execute code that would change the sequence length directly. But other threads could change it, as could a custom __eq__ on an object stored in the sequence (or a poorly implemented __getitem__ or __len__ on the sequence itself, but that's getting even more pathological). Thread consistency is the code's responsibility though (we just need to make sure we behave the best we can, and hope they use locks correctly), and the odds of equality of __getitem__ altering the sequence are much lower than the odds of someone iterating the sequence and changing it as they go (which is what __iter__'s implementation allows, responding with potentially incomplete results since items might be skipped due to the mutation), but keeping the sequence in a consistent state.

I'm going to add a test case that changes the sequence length during .index(), and just do whatever list does in that case.

I take it back, I don't want to copy what the list type does, because it's wrong: http://bugs.python.org/issue23204

I'm afraid you're getting lost in details that don't matter.   We're trying to make the index() method more useful so that searches and be restarted where they left off.

I afraid that the patch can change computational complexity. The iteration usually has linear complexity, but indexing can has non-constant complexity. E.g. for linked list it will cause quadratic complexity of index(). May be we should have special case for start=0 and stop=None. And document this.

> The iteration usually has linear complexity

The iteration abstract method depends on indexing as well:

    def __iter__(self):
        i = 0
        try:
            while True:
                v = self[i]
                yield v
                i += 1
        except IndexError:
            return

I inferred from Serhiy's comment that if you override __iter__ to be efficient and not use __getitem__, this overridden behavior used to pass on to index(), but wouldn't after this patch.

New changeset cabd7261ae80 by Raymond Hettinger in branch 'default':
Issue #23086: Add start and stop arguments to the Sequence.index() mixin method.
https://hg.python.org/cpython/rev/cabd7261ae80

Devin, thanks for the patch.

Serhiy, I added a performance note discussing the computational complexity.