[Python-ideas] Generator unpacking

[Andrew Barnert]

On Feb 15, 2016, at 19:47, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
> 
>> On 15/02/2016 23:54, Andrew Barnert via Python-ideas wrote:
>>> On Feb 15, 2016, at 14:41, Brendan Barnwell <brenbarn at brenbarn.net> wrote:
>>>>> On 2016-02-15 14:27, Andrew Barnert wrote:
>>>>> Of course any useful definition would leave pathological types that
>>>>> are neither iterator nor collection (e.g., an object that returns a
>>>>> new iterator each time, but those iterators destructively modify
>>>>> self), or maybe where they do qualify but misleadingly so (I can't
>>>>> think of any examples). And there may also be cases where it isn't
>>>>> clear (e.g., is a collection of shared memory not a collection
>>>>> because some other process can change its values, or does that count
>>>>> as "unless mutated"? that probably depends on how and why your app is
>>>>> using that shared memory). 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.
>>>> <snip>
>>>> Because iterators and collections are
>>>> both iterable, just knowing that something is an iterable doesn't
>>>> tell you whether it's reusable. But knowing that something is a
>>>> collection (assuming we have a well-defined term "collection") would.
>>>> Which is exactly the point of the proposal.
>>>    I still don't understand why you want to use the term "collection" when everything you say about the purpose of the term (as for instance your last paragraph here) suggests you want to know whether it is reusable. To ordinary humans "collection" says nothing about iteration or reusability.
>> First, the word "reiterable" is acceptable to me (and certainly better than not having any such term)--that's why I said "like 'reiterable' or 'collection'" multiple times. It's an easy-to-remember term, and it's name helps keep it straight. The biggest problem is that it's not an actual word, and it looks and sounds ugly. It's much better than not having a word at all, and forcing people to use phrases like "reusable non-iterator iterable", but it's not ideal.
>> 
>> The reason "collection" is better is that it matches an intuitive category that actually means what we want. 
>> 
>> And the fact that it's not immediately obvious [my emphasis - RC] that it does what we want is a _good_ thing, because it means people have one simple thing to learn and remember: you can iterate collections over and over without affecting them.
> So you'd rather people learned the word "collection" (which does not convey that they are reiterable) and then *learned* that collections can be iterated over repeatedly, than learn the word "reiterable" that makes it immediately obvious that something can be iterated over repeatedly.
> Why make life more difficult?  How is that a "_good_ thing"?

Because "reiterable" is really not immediately obvious. It has no intuitive meaning; it's not even a real word. You have to learn what a reiterable is, by definition. That's no easier than learning a simple fact about collections, and you end up knowing less after that learning.

Think of my random example. Is that a reiterable? Well, you can call iter on its multiple times and get different iterators. But they don't iterate the same value. So, yes or no? There's no intuition to guide you there; all you have is a definitional rule that you had to memorize.

Similarly, you can't meaningfully attach adjectives to "reiterable" that restrict or expand its scope. "Lazy reiterable" doesn't mean anything; "lazy collection" does.

But I've already made all these points and you just skipped over them. 

And more importantly, as I've already said, I'd be very happy for "reiterable" to be added to the glossary and maybe the ABCs--it's not as good as "collection", but it's a lot better than nothing--so I don't really want to argue against it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160215/0ed24314/attachment.html>