Antoine Pitrou wrote: > First, you can't implement __length_hint__ for a generator, which is the > preferred (the most practical) way of writing iterators in pure Python. Limitations of generators are no reason for not improving iterators which are not generators. __length_hint__ already exists; this proposal simply proposes making it documented and officially supported. py> iter([]).__length_hint__ <built-in method __length_hint__ of list_iterator object at 0xb7bcf98c> > Even if __length_hint__ is implemented, its result may be wrong. > That's the whole point: it's a *hint*; an iterator might tell you it's > finite while it's infinite, or the reverse. If it claims to be infinite, I see no reason to disbelieve it on the off-chance that it is actually both finite and small enough to fit into memory without crashing my system. If it claims to be finite, but is actually infinite, well that's not much of a hint, is it? There's an implied promise that the hint will be close to the real value, not infinitely distant. > My conclusion is that an infinite iterator is a documentation issue. > Just tell the user that it doesn't stop, and let them shoot themselves > in the foot in they want to. Buffer overflows are a documentation issue. Just tell the user not to overwrite memory they don't mean to, and let them shoot themselves in the foot if they want. *wink* -- Steven
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4