Message292287
> I explored that notion of iterator length transparency years ago. While I don't remember all the details, I did record some notes at the top of Lib/test/test_iterlen.py.
But isn't that the point of the length_hint? To provide an *estimate* for the length? So generally I would expect the length_hint to be accurate (at least accurate enough to avoid reallocations) for well-behaved iterators. And I think that's possible for "zip" and "map" (but also for several itertools: product, permutations, combinations, islice, accumulate, starmap, zip_longest). At least in theory.
Also it would allow to prohibit infinite iterators to be passed to "length_hint"-aware functions. For example `list(count())` could raise an exception when `count.length_hint` would return math.inf or sys.maxsize + 1.
The pull request was just because I was curious how it performed and wanted to share the code. Feel free to reject it. The performance improvement wasn't amazing in the micro-benchmarks. |
|
Date |
User |
Action |
Args |
2017-04-25 23:31:29 | MSeifert | set | recipients:
+ MSeifert, rhettinger, terry.reedy, vstinner, alex, serhiy.storchaka |
2017-04-25 23:31:29 | MSeifert | set | messageid: <1493163089.25.0.104602412873.issue26828@psf.upfronthosting.co.za> |
2017-04-25 23:31:29 | MSeifert | link | issue26828 messages |
2017-04-25 23:31:29 | MSeifert | create | |
|