Replies: 4 comments 8 replies
-
The docs on iterator types say this:
So that implies the type shouldn't be relied on. I think the only functionality that might be relevant to compatibility is pickling, but actually they just produce an |
Beta Was this translation helpful? Give feedback.
-
It seems innocent enough. I just wonder if there's enough of a benefit, given that such an iterator will only be used for small ranges? |
Beta Was this translation helpful? Give feedback.
-
I added this to specialize.c: if (t == &PyRangeIter_Type) {
+ rangeiterobject *r = (rangeiterobject *)iter;
+ if (r->step == 1 && r->start >= -5 && r->start + r->len <= 257) {
+ return SPEC_FAIL_FOR_ITER_SMALLRANGE;
+ }
return SPEC_FAIL_FOR_ITER_RANGE;
} Then took stats of some of pyperformance, broken down by benchmark: https://gist.github.com/sweeneyde/26a67de173e6dfbe9f715e2457ce753d It seems some benchmarks primarily use small-int ranges. Patch is here: https://github.com/python/cpython/compare/main...sweeneyde:smallrangeiter?expand=1 TODO: Benchmarks |
Beta Was this translation helpful? Give feedback.
-
I wonder if we could somehow instrument how often this applies in e.g. the PyPerformance benchmark suite. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Current implementation of rangeiterator
Proposal to add another type:
Then on
range.__iter__
, instead of just two branches (rangeiter and longrangeiter), this would be a third.Are there backward-compatibility concerns about what the type of an iterator is? It's already standard that range iterators use different types for big numbers, so maybe it wouldn't be too bad to have a different type for this common small case?
Beta Was this translation helpful? Give feedback.
All reactions