You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add start and stop parameters to the Sequence.index() ABC mixin method #67275
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:
assignee='https://github.com/rhettinger'closed_at=<Date2015-05-23.02:31:23.191>created_at=<Date2014-12-18.20:41:46.585>labels= ['type-feature', 'library']
title='Add start and stop parameters to the Sequence.index() ABC mixin method'updated_at=<Date2015-05-23.02:31:23.190>user='https://github.com/rhettinger'
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.
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.
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.
ssbr commented on Jan 7, 2015
ssbrmannequin
Mannequin
More actions
Why is there no "review" link next to my second patch?
Are you sure? I noticed that __iter__ went out of its way to avoid calling len().
MojoVampire commented on Jan 8, 2015
MojoVampiremannequin
Mannequin
More actions
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.
MojoVampire commented on Jan 8, 2015
MojoVampiremannequin
Mannequin
More actions
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.
ssbr commented on Jan 8, 2015
ssbrmannequin
Mannequin
More actions
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'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.
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.
Activity
rhettinger commentedon Dec 18, 2014
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.
ssbr commentedon Jan 5, 2015
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.
rhettinger commentedon Jan 7, 2015
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:
ssbr commentedon Jan 7, 2015
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.
ssbr commentedon Jan 7, 2015
Why is there no "review" link next to my second patch?
rhettinger commentedon Jan 8, 2015
Try something like this:
ssbr commentedon Jan 8, 2015
Are you sure? I noticed that __iter__ went out of its way to avoid calling len().
MojoVampire commentedon Jan 8, 2015
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.
MojoVampire commentedon Jan 8, 2015
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.
ssbr commentedon Jan 8, 2015
I'm going to add a test case that changes the sequence length during .index(), and just do whatever list does in that case.
ssbr commentedon Jan 9, 2015
I take it back, I don't want to copy what the list type does, because it's wrong: http://bugs.python.org/issue23204
rhettinger commentedon Jan 9, 2015
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.
serhiy-storchaka commentedon Jan 9, 2015
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.
rhettinger commentedon Jan 9, 2015
The iteration abstract method depends on indexing as well:
ssbr commentedon Jan 10, 2015
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.
python-dev commentedon May 23, 2015
New changeset cabd7261ae80 by Raymond Hettinger in branch 'default':
Issue bpo-23086: Add start and stop arguments to the Sequence.index() mixin method.
https://hg.python.org/cpython/rev/cabd7261ae80
rhettinger commentedon May 23, 2015
Devin, thanks for the patch.
Serhiy, I added a performance note discussing the computational complexity.