[Python-3000] have zip() raise exception for sequences of different lengths

Steven Bethard steven.bethard at gmail.com
Thu Aug 31 01:33:27 CEST 2006

On 8/30/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> Until now, there have been zero requests for zip() to have exception
> raising behavior.
> For Python 3k, I recommend:
> * simply replacing zip() with itertools.izip()
> * keeping the zip_longest() in a separate module
> * punting on an exception raising version
> The first covers 99% of use cases.

I guess it depends what you mean by "covers".  If you mean "produces
the correct output for correct input" then yes, it does, but so would
the exception raising one.  I contend that it often does the wrong
thing for incorrect input by silently truncating. To try to give a
fair evaluation of this contention, I looked at some stdlib examples
and tried to classify them:

Examples where different lengths should be an error:

compiler/pycodegen.py:        for i, for_ in
zip(range(len(node.quals)), node.quals):
dis.py:    for byte_incr, line_incr in zip(byte_increments, line_increments):
email/Header.py:        return zip(chunks, [charset]*len(chunks))
filecmp.py:        a = dict(izip(imap(os.path.normcase,
self.left_list), self.left_list))
idlelib/keybindingDialog.py:        for modifier, variable in
zip(self.modifiers, self.modifier_vars):

Examples where truncation is needed:

csv.py:        d = dict(zip(self.fieldnames, row))
idlelib/EditorWindow.py:            for i, file in zip(count(), rf_list):

A couple of the examples (pycodegen.py, EditorWindow.py) are really
just performing a poor-man's enumerate(), but with a cursory glance it
still looks to me like there are more cases in the stdlib where it is
a programming error to have lists of different sizes.

If changing zip()'s behavior to match the most common use case is
totally out, the stdlib code at least argues for adding something like

I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

More information about the Python-3000 mailing list