On Tue, Jul 17, 2012 at 12:01 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 16 Jul 2012 23:23:18 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: >> >> - distinguishing between different reasons for saying "don't >> preallocate any space" (i.e. returning zero). I still haven't heard a >> convincing rationale for this one > > The point is that zero is a valid value for a length hint. By making it > a special value for "don't know", you are making the protocol > potentially confusing, and you are also departing from the current > semantics.
No, it just means the default estimate is always zero. If you don't do that, then *every* client of __length_hint__ has to check for the magic value. It's making the API harder to use for no good reason. > (and, yes, I think distinguishing between zero and "don't know" is > useful: imagine a container that would preallocate 256 entries by > default when the answer is "don't know") Such a container has to already deal with the case when it overestimates severely. The only cost of using zero as a default estimate is that such hypothetical containers will overallocate when they technically didn't need to, which will already happen for any empty iterator that doesn't provide __length_hint__ at all. Given that all standard library containers default to assuming a size of zero (absent information indicating otherwise), and a special value would need to be special cased by *every* client of the API (and almost always defaulted to zero), it's simply not a good trade-off. >> The PEP itself already has this general tone, but I think that it >> should be even more emphatic that it's about codifying the status quo, >> *not* about modifying it with ideas haven't been proven useful through >> past experience. > > Then the PEP shouldn't address infinite iterators at all. Noting that infinite iterators are free to define __length_hint__ to always throw an exception *is* the status quo. We just haven't done it for the stdlib ones. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com