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 "<stdin>", line 1, in <module>
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.

Would you like to submit a patch?

What would happen with infinite iterables?

import itertools 
[foo] = itertools.count()

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.

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/

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.'

Applied patch in r82759.