Zen of Python: Errors should never pass silently. Why does zip work the way it does?
<p>I use python's function zip a lot in my code (mostly to create dicts like below) </p>

<pre><code>dict(zip(list_a, list_b)) 
</code></pre>

<p>I find it really useful, but sometimes it frustrates me because I end up with a situation where list_a is a different length to list_b. zip just goes ahead and zips together the two lists until it achieves a zipped list that is the same length as the shorter list, ignoring the rest of the longer list. This seems like it should be treated as an error in most circumstances, which according to the zen of python should never pass silently. </p>

<p>Given that this is such an integral function, I'm curious as to why it's been designed this way? Why isn't it treated as an error if you try to zip together two lists of different lengths?</p>

<h2>Reason 1: Historical Reason</h2>

<p><code>zip</code> allows unequal-length arguments because it was meant to improve upon <code>map</code> by <em>allowing</em> unequal-length arguments. This behavior is the reason <code>zip</code> exists at all.</p>

<p>Here's how you did <code>zip</code> before it existed:</p>

<pre><code>&gt;&gt;&gt; a = (1, 2, 3)
&gt;&gt;&gt; b = (4, 5, 6)
&gt;&gt;&gt; for i in map(None, a, b): print i
...
(1, 4)
(2, 5)
(3, 6)
&gt;&gt;&gt; map(None, a, b)
[(1, 4), (2, 5), (3, 6)]
</code></pre>

<p>This is terrible behaviour, and <em>does not</em> support unequal-length lists. This was a major design concern, which you can see plain-as-day in <a href="https://www.python.org/dev/peps/pep-0201/#lockstep-for-loops">the official RFC proposing <code>zip</code> for the first time</a>:</p>

<blockquote>
  <p>While the map() idiom is a common one in Python, it has several
  disadvantages:</p>
  
  <ul>
  <li><p>It is non-obvious to programmers without a functional programming
  background.</p></li>
  <li><p>The use of the magic <code>None</code> first argument is non-obvious.</p></li>
  <li><p>It has arbitrary, often unintended, and inflexible semantics when the
  lists are not of the same length - the shorter sequences are padded
  with <code>None</code> :</p>
  
  <p><code>&gt;&gt;&gt; c = (4, 5, 6, 7)</code></p>
  
  <p><code>&gt;&gt;&gt; map(None, a, c)</code></p>
  
  <p><code>[(1, 4), (2, 5), (3, 6), (None, 7)]</code></p></li>
  </ul>
</blockquote>

<p>So, no, this behaviour would not be treated as an error - it is <em>why it was designed in the first place</em>.</p>

<hr>

<h2>Reason 2: Practical Reason</h2>

<p>Because it is pretty useful, is clearly specified and doesn't have to be thought of as an error at all. </p>

<p>By allowing unequal lengths, <code>zip</code> only requires that its arguments conform to the <a href="http://stackoverflow.com/questions/16301253/what-exactly-is-pythons-iterator-protocol">iterator protocol</a>. This allows <code>zip</code> to be extended to generators, tuples, dictionary keys and literally anything in the world that implements <code>__next__()</code> and <code>__iter__()</code>, precisely because it doesn't inquire about length. </p>

<p>This is significant, because generators <em>do not</em> support <code>len()</code> and thus there is no way to check the length beforehand. Add a check for length, and you break <code>zip</code>s ability to work on generators, <em>when it should</em>. That's a fairly serious disadvantage, wouldn't you agree?</p>

<hr>

<h2>Reason 3: By Fiat</h2>

<p>Guido van Rossum wanted it this way:</p>

<blockquote>
  <p><em>Optional padding.</em> An earlier version of this PEP proposed an optional pad keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. <strong>This has been rejected by the BDFL in favor of always truncating to the shortest sequence, because of the KISS principle.</strong> If there's a true need, it is easier to add later. If it is not needed, it would still be impossible to delete it in the future.</p>
</blockquote>

<p>KISS trumps everything.</p>

python