This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author MSeifert
Recipients MSeifert, alex, rhettinger, serhiy.storchaka, terry.reedy, vstinner
Date 2017-04-25.23:31:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493163089.25.0.104602412873.issue26828@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2017-04-25 23:31:29MSeifertsetrecipients: + MSeifert, rhettinger, terry.reedy, vstinner, alex, serhiy.storchaka
2017-04-25 23:31:29MSeifertsetmessageid: <1493163089.25.0.104602412873.issue26828@psf.upfronthosting.co.za>
2017-04-25 23:31:29MSeifertlinkissue26828 messages
2017-04-25 23:31:29MSeifertcreate