Misleading error message of the day

[Ethan Furman]

If the RHS was a tuple or a list, yes you could know immediately. But
unpacking works with any iterable, so it probably doesn't special-case
lists and tuples. Iterables don't have a size- they just keep going
until StopIteration is raised. So in EVERY SINGLE CASE, you would get
"expected n args, got n+1" even if the iterable would return 24 items
instead of 14, or would never stop returning items.

Not so. There could be fewer, in which you could see "expected 13 args,
got 7."

~Ethan~

 

[Benjamin Kaplan]

Not so.  There could be fewer, in which you could see "expected 13 args, got
7."

You mean like this?

a,b,c = ['a','b']

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: need more than 2 values to unpack

 

[Jean-Michel Pichavant]

Yes, I understand that the exception is correct. I'm not saying the exception should be changed, just that we have the opportunity to produce a more useful error message. The exception would be equally correct if it was:

ValueError: you did something wrong

but most people would probably agree that it's not the most useful message that could have been produced.

You have to opportunity to not use unpacking anymore ) There is a
recent thread were the dark side of unpacking was exposed. Unpacking is
a cool feautre for very small applications but should be avoided
whenever possible otherwise.

JM

 

[Robert Kern]

Iterator unpacking works roughly thus:

1) Count up how many results you need (call that N)
2) N times, get a value from the iterator. If StopIteration is raised,
swallow it and raise ValueError because there were too few values.
3) Attempt to get one more value from the iterator. If StopIteration
is NOT raised, raise ValueError because there were too many values.

At no point is the "total size" of the iterator counted (it could,
after all, be infinite). When ValueError is raised, all that's known
is that StopIteration wasn't raised at the end of the process.

unpack_iterable() has the original object available to it, not just the
iterator. It could opportunistically check for __len__() and fall back to the
less informative message when it is absent.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Ethan Furman]

Not so. There could be fewer, in which you could see "expected 13 args, got
7."

You mean like this?

a,b,c = ['a','b']

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: need more than 2 values to unpack

This is still not as helpful as this would be:

ValueError: need 3 values, received 2

~Ethan~

 

[Ethan Furman]

You have to opportunity to not use unpacking anymore ) There is a
recent thread were the dark side of unpacking was exposed. Unpacking is
a cool feautre for very small applications but should be avoided
whenever possible otherwise.

Which thread was that?


~Ethan~

 

[alister]

My favorite is still the old classic error from and old Unix printer
port driver:

"lp0 on fire"

not as useless as "Keyboard Error press F1 to continue"

 

[Chris Angelico]

not as useless as "Keyboard Error press F1 to continue"

If it said "press F1 to ignore" then I would agree. This, however, is
more akin to "replace user and strike any key to continue", but more
implicit.

ChrisA

 

[Roy Smith]

My favorite is still the old classic error from and old Unix printer
port driver:

"lp0 on fire"

Well, if you're going to go there, ed had (and probably still does) have
but a single all-purpose error message: "?".

The old v6 unix chess program was somewhat more verbose. It said, "eh?"
(unless I'm mixing that up with something else).

 

[Lie Ryan]

Which thread was that?

perhaps the one that talks about `a, a.foo = 1, 2` blowing up?

 

[Steven D'Aprano]

My favorite is still the old classic error from and old Unix printer
port driver:

"lp0 on fire"

I forget where I saw this, but somebody took a screen shot of an error
message from a GUI application that said something like:

A fatal error occurred: no error

and then aborted the app.

 

[Chris Angelico]

I forget where I saw this, but somebody took a screen shot of an error
message from a GUI application that said something like:

A fatal error occurred: no error

and then aborted the app.

An errant error! Sounds like the stuff that happens here...

http://thedailywtf.com/Series/Error_0x27_d.aspx

This is getting quite off-topic though.

ChrisA

 

[Roy Smith]

http://thedailywtf.com/Series/Error_0x27_d.aspx

This is getting quite off-topic though.

Getting off-topic, perhaps, but your comment really does bring some
closure. When I was pondering the original, "too many values to unpack"
message, I did indeed utter a few WTFs

 

[alex23]

perhaps the one that talks about `a, a.foo = 1, 2` blowing up?

Are you sure you're not confusing this with the recent thread on 'x =
x.thing = 1'?

 

[Jean-Michel Pichavant]

Which thread was that?


~Ethan~

"A tuple in order to pass returned values ?" was the thread.

JM

 

[Roy Smith]

"A tuple in order to pass returned values ?" was the thread.

JM

To save everybody the effort of finding it, I think he's talking about
https://groups.google.com/d/topic/comp.lang.python/2vcwYfIQSOM/discussion

 

[Ethan Furman]

"A tuple in order to pass returned values ?" was the thread.

Thanks.

~Ethan~

 

[Lie Ryan]

Are you sure you're not confusing this with the recent thread on 'x =
x.thing = 1'?

Ah, yes I do