[Python-ideas] Generator unpacking

Brendan Barnwell brenbarn at brenbarn.net
Mon Feb 15 17:41:22 EST 2016


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.  If you want to say it's reusable, just say it's reusable. 
  As a bonus, you don't have to get anyone to buy into a term like 
"collection", or even know the difference between iterators and 
iterables, because "reusable iterator" and "reusable iterable" (or 
"re-iterable", or "restartable" or other such terms) already have an 
obvious interpretation (even if one of them is technically impossible).

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
    --author unknown


More information about the Python-ideas mailing list