Python Iterables struggling using map() built-in

[Ned Batchelder]

On 12/7/14 7:12 PM, Roy Smith wrote:
> Chris Angelico wrote:
>>> I'm actually glad PEP 479 will break this kind of code. Gives a good
>>> excuse for rewriting it to be more readable.
>
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> What kind of code is that? Short, simple, Pythonic and elegant? :-)
>>
>> Here's the code again, with indentation fixed:
>>
>>
>> def myzip(*args):
>>      iters = map(iter, args)
>>      while iters:
>>          res = [next(i) for i in iters]
>>          yield tuple(res)
>
> Ugh.  When I see "while foo", my brain says, "OK, you're about to see a
> loop which is controlled by the value of foo being changed inside the
> loop".  That's not at all what's happening here, so my brain runs into a
> wall.
>
> Next problem, what the heck is "res"?  We're not back in the punch-card
> days.  We don't have to abbreviate variable names to save columns.
> Variable names are supposed to describe what they hold, and thus help
> you understand the code.  I have no idea what "res" is supposed to be.
> Residue?  Result?  Rest_of_items?  Response?  None of these make much
> sense here, so I'm just left befuddled.
>
>> It would be even more beautiful if we get rid of the unnecessary temporary
>> variable:
>>
>> def myzip(*args):
>>      iters = map(iter, args)
>>      while iters:
>>          yield tuple([next(i) for i in iters])
>
> Well, that's one way to solve the mystery of what "res" means, but it
> doesn't actually make it easier to understand.
>
>> I think this function makes a good test to separate the masters from the
>> apprentices.
>
> The goal of good code is NOT to separate the masters from the
> apprentices.  The goal of good code is to be correct and easy to
> understand by the next guy who comes along to maintain it.
>
>> If you can read this function and instantly tell how it works, that it is
>> bug-free and duplicates the behaviour of the built-in zip(), you're
>> probably Raymond Hettinger. If you can tell what it does but you have to
>> think about it for a minute or two before you understand why it works, you
>> can call yourself a Python master. If you have to sit down with the
>> interactive interpreter and experiment for a bit to understand it, you're
>> doing pretty well.
>
> That pretty much is the point I'm trying to make.  If the code is so
> complicated that masters can only understand it after a couple of
> minutes of thought, and those of us who are just "doing pretty well"
> need to sit down and puzzle it out in the REPL, then it's too
> complicated for most people to understand.  KISS beats elegant.
>

Now that I understand all the intricacies (thanks everyone!), this is 
how I would write it:

     def zip(*args):
         if not args:
             return
         iters = list(map(iter, args))
         while True:
             try:
                 result = [next(it) for it in iters]
             except StopIteration:
                 return
             yield tuple(result)

The implicit use of StopIteration to end the entire generator is far too 
implicit for my taste.  This code expresses the intent much better.

And good call on not being able to use:

     tuple(next(it) for it in iters)

Again, the tricky implicit hidden StopIterations are confusing.

One last tweak: why do we use map to make iters, but a list 
comprehension to make result?  OK, let's try this:

     result = map(next, iters)

Oops, another infinite loop on Py3, right, because map is lazy, so the 
StopIteration doesn't happen until the tuple() call.  OK, try this:

     result = list(map(next, iters))

Nope, still infinite because now list() consumes the StopIteration 
again. Ugh.

-- 
Ned Batchelder, http://nedbatchelder.com