On Jun 7, 8:22�pm, John Salerno <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
