[issue31108] add __contains__ for list_iterator (and others) for better performance

Changes by Serhiy Storchaka : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31108] add __contains__ for list_iterator (and others) for better performance

Raymond Hettinger added the comment: I recommend rejecting this proposal -- ___ Python tracker ___ ___

[issue31108] add __contains__ for list_iterator (and others) for better performance

Antoine Pitrou added the comment: I don't think I've ever used `in` on an iterator. I didn't even expect it to work, and would not consider its use a good practice. -- nosy: +pitrou ___ Python tracker

[issue31108] add __contains__ for list_iterator (and others) for better performance

Terry J. Reedy added the comment: Sorry, I mistakenly assumed, without carefully checking the C code, that the speedup was from checking the underlying collection, without advancing the iterator. I presume that " ++it->it_index;" is the statement to the contrary. I should have either asked

[issue31108] add __contains__ for list_iterator (and others) for better performance

Changes by Terry J. Reedy : -- Removed message: http://bugs.python.org/msg299770 ___ Python tracker ___

[issue31108] add __contains__ for list_iterator (and others) for better performance

Serhiy Storchaka added the comment: Terry, this proposition doesn't change the behavior. It moves the iterator forward during searching. The only effect is inlining __next__ in a loop and getting rid of the overhead of few indirections and calls. --

[issue31108] add __contains__ for list_iterator (and others) for better performance

Terry J. Reedy added the comment: On my particular Win 10 machine with 3.6, the times are 1.52 and 2.14. But to me, the times are irrelevant. A performance enhancement, by definition, should not change computational results, but this does. If an iterator is a standard iterator, then 'x in

[issue31108] add __contains__ for list_iterator (and others) for better performance

Serhiy Storchaka added the comment: The patch adds almost 40 line of the code and increases the performance of not well famous feature at best by 10-20%. Adding an optimization for every new iterator type will add a comparable quantity of the code. I think this is too high cost. Using a

[issue31108] add __contains__ for list_iterator (and others) for better performance

New submission from Sergey Fedoseev: > python -mtimeit -s "l = list(range(10))" "l[-1] in l" 1000 loops, best of 3: 1.34 msec per loop > python -mtimeit -s "l = list(range(10))" "l[-1] in iter(l)" > 1000 loops, best of 3: 1.59 msec per loop --

[issue31108] add __contains__ for list_iterator (and others) for better performance

Changes by Sergey Fedoseev : -- pull_requests: +3025 ___ Python tracker ___ ___