[Python-ideas] Generator unpacking
Andrew Barnert
abarnert at yahoo.com
Tue Feb 16 00:56:14 EST 2016
On Feb 15, 2016, at 19:42, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>
> Andrew Barnert via Python-ideas writes:
>
>> But that isn't a problem; we're not trying to come up with a
>> definition that could be used to write type-theoretic behavior
>> proofs for Python semantics, but something that's useful in
>> practice for discussing almost all real Python programs with other
>> humans.
>
> Are there really places where we *want* "foo(range(n))" to raise but
> "foo(iter(range(n)))" to do something useful? In other words, is this
> really a terminology problem, rather than a problem with the design of
> APIs that take iterators rather than iterables?
Sure. Any multi-pass algorithm should raise when given an iterator. (Maybe some could instead copy the iterator to a list or something, but as a general rule, silently and unexpectedly jumping from 0 to O(N) space depending on the input type isn't very friendly.)
In the other direction, of course, the next function requires an iterator, and should and does raise when given something else. And the slightly higher-level functions discussed in this thread are the same. A function intended to consume and return the first few values in an iterator while leaving the iterator holding the rest is basically just a "multinext", and it would be very confusing if it took a collection and left it holding all the values, including the two you already used. And how do you explain that to a human? You could say "While it's an iterable, it's not an iterator." And that's exactly what Python has said for the last however-many years. And that's exactly what leads to the confusion Paul was talking about (and the additional confusion he inadvertently revealed). And the problem isn't "Paul is an idiot", because I've seen multiple core devs, and other highly experienced Python programmers, make the same mistake. Even the official docs made a similar mistake, and nobody caught it for 4 years. If the current terminology were sufficiently clear and intuitive that nothing needed to be done, these problems wouldn't exist.
More information about the Python-ideas
mailing list