Issue 3071: The ValueError raised by failing to unpack sequence should have more information. (original) (raw)

Created on 2008-06-10 02:06 by jml, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg67885 - (view)	Author: Jonathan Lange (jml)	Date: 2008-06-10 02:06
Here's the current message: Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> [foo] = [2, 3] Traceback (most recent call last): File "", line 1, in ValueError: too many values to unpack It would be good if the message of the ValueError contained information about how many values were expected and how many values were given.
msg67889 - (view)	Author: Benjamin Peterson (benjamin.peterson) *	Date: 2008-06-10 02:46
Would you like to submit a patch?
msg87920 - (view)	Author: Daniel Diniz (ajaksu2) *	Date: 2009-05-16 20:33
What would happen with infinite iterables? import itertools [foo] = itertools.count()
msg90968 - (view)	Author: Jack Diederich (jackdied) *	Date: 2009-07-27 00:12
The code that raises the error is in ceval.c which is a critical path. The raise is done as soon the iterator has one more item than is needed (see Daniel Diniz's comments on infinite iterators). While the check could return more useful information for known non-infinite iterators (tuples, lists, etc) it would have to do a big if/else for all the core types (but excluding their subclasses!). If someone wants to submit that patch and a benchmark that shows no slowdown I'll reopen the bug. Until then I'm closing as WONTFIX.
msg90972 - (view)	Author: Jean-Paul Calderone (exarkun) *	Date: 2009-07-27 02:35
Here's a patch implementing part of the requested feature. pystones cannot tell the difference between trunk@HEAD with or without this patch applied. Both report a maximum of 78125 pystones/second/
msg90974 - (view)	Author: Jack Diederich (jackdied) *	Date: 2009-07-27 03:46
I was looking at 3.x, JP's patch is relative to 2.x and takes a little more unpacking (a couple function calls more) but looks to me to be the same. In 2.x unpack_iterable() sets/returns an error once one item more than is required is received. It doesn't give any more information about known-length builtins than anything else. The same error is raised for million-item lists as three item lists if the expected number to unpack is two. The original feature request was that the error message be better if, say the left hand side wanted three arguments and the right hand side provided four. The ceval.c code is different between 2.x and 3.x but they both only check for 'exactly the right number, or one or more too many.'
msg109843 - (view)	Author: Georg Brandl (georg.brandl) *	Date: 2010-07-10 10:32
Applied patch in r82759.