Alex Gaynor, 15.07.2012 07:20: > there's no way for the __lenght_hint__ to specify that > that particular instance can't have a length hint computed. e.g. imagine > some sort of lazy stream that cached itself, and only wanted to offer a > length hint if it had already been evaluated. Without an exception to > raise, it has to return whatever the magic value for length_hint is (in > your impl it appears to be 0, the current _PyObject_LengthHint method in > CPython has a required `default` parameter). The PEP proposes using > TypeError for that.
Yes, that's a major issue. I've been planning to add a length hint to Cython's generator expressions for a while, but the problem is really that in most cases it is only known at runtime if the underlying iterable has a length hint, so propagating it needs a way to say "sorry, I thought I might know, but I don't". It would be even better if this way was efficient. Since we're at a point of making this an official protocol, why not change the current behaviour and return -1 (or even just 0) to explicitly state that "we don't know"? The problem with an exception here is that it might have been raised accidentally inside of the __length_hint__() implementation that is being asked. Swallowing it just because it happened to be a TypeError rather than something else may end up covering bugs. We had a similar issue with hasattr() in the past. Also, it would be nice if this became a type slot rather than requiring a dict lookup and Python function call. Stefan _______________________________________________ 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
