Do this as a list comprehension?

[Mensanator]

On Jun 7, 8:22�pm, John Salerno <johnj... at gmailNOSPAM.com> wrote:
> Mensanator wrote:
> > What I DID say was that how the builtins actually
> > work should be understood and it APPEARED that the
> > OP didn't understand that. Maybe he understood that
> > all along but his example betrayed no evidence of
> > that understanding.
>
> Well, the truth is that I know zip truncates to the shorter of the two
> arguments,

Ok, sorry I thought otherwise.

> and also in my case the two arguments would always be the
> same length.

Yes, because you're controlling the source code.
But since lists are mutable, source code literals
don't always control the length of the list.

> But it is still helpful for other people to point out to me
> potential problems like this,

My intentions were always to be helpful, not arrogant.
Otherwise, I'd just tell you to go RTFM. I do seem to have
a gift for rubbing people the wrong way.

What's important at the end of the day is that you
have a working program, right?

> so I can be aware of it the next time I
> might want to use zip with unequal length arguments.

There are, of course, situations where that's
desireable, that's why I said such behaviour is
by design. It's much easier to debug a program
that crahes than one that works but gives you
the wrong answer. You'll find the "out of range"
errors readily enough, it's when the list is longer
than the range and the answer comes up short that
are hard to spot.

That previous example I gave you? I've run that
with a list of over 800,000 numbers, far too many
to manually verify. I must have absolute confidence
that the algorithm works correctly. That's what
you should strive for - confidence that things will
work even when you can't manually verify them.