[Python-ideas] iterable.__unpack__ method

[Terry Reedy]

On 2/24/2013 5:07 PM, Alex Stewart wrote:

> ==== Unpacking protocol
>
> First, there is the question I originally raised about separating the
> "unpacking protocol" from the "iterator protocol".  I would like to
> clarify a couple of points on this:
>
> I proposed __unpack__ the way I did specifically for a few reasons:
>
>  1. It is a fairly small change to the language

To me, taking something simple and elegant and complexifying it, to 
little benefit I can see other than to solve a problem in the wrong 
place, in no small matter. Certainly, adding a new special method to 
some category of objects has not effect unless changes are made to the 
interpreter elsewhere to make automatic use of that method. Otherwise, 
you could just define a normal method to be used by user code.

>  2. There are (in my opinion) already pretty good parallels with this
>     sort of change that have already been implemented in Python (for
>     example, separating the concept of "iterable" from the concept of
>     "indexable").

The related but distinct concepts of sequential access and random access 
are basic to computation and were *always* distinct in Python. For loop 
statements were always the way to sequentially access objects in a 
collection (by default, all of them). It happens that the original 
*implementation* of sequential access, use by for loops, was by means of 
pseudo random access. This worked ok for randomly accessible sequences 
but was clumsy for anything else. (Sequential access requires memory, 
random access does not.) The addition of __iter__ along with __next__ 
added more benefits than __next__ alone would have.

>  3. It is consistent with the general idea in Python that an object can
>     choose to emulate whichever behaviors of other objects make sense,
>     and not emulate other ones that do not make sense.  In my opinion,
>     "iterating", and "unpacking" are two related-but-not-the-same
>     language concepts, which currently are unnecessarily entangled.

I do not see that at all. As near as I can tell, both mean 'sequential 
access'. You are that one that seems to me to be entangling 'bind 
objects to targets one at a time' with 'provide objects one at a time'. 
The point of both old and new iterator protocols was and is to decouple 
(disentangle) consumers from providers. At one time, target-list binding 
*was* entangled -- with tuples -- because it did not use the iterator 
protocol that for statement did.

I admit I do not understand your __unpack__ proposal, since it seemed 
vague and incomplete to me. But until I see your conceptual distinction, 
the details do not matter to me.

>  4. It would help significantly with several types of problems that do
>     not currently have great solutions.

I obviously do not see the same pile of problems that would justify a 
new special method.

...
> no way to query an iterator to find out if it has more data available

See how in my separate post:
"Add lookahead iterator (peeker) to itertools"

-- 
Terry Jan Reedy