Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #16829 > unrolled thread

Misleading error message of the day

Back to article view | Back to comp.lang.python

Contents

  Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 09:23 -0500
    Re: Misleading error message of the day Andrea Crotti <andrea.crotti.0@gmail.com> - 2011-12-08 14:39 +0000
    Re: Misleading error message of the day Chris Angelico <rosuav@gmail.com> - 2011-12-09 01:40 +1100
    Re: Misleading error message of the day Robert Kern <robert.kern@gmail.com> - 2011-12-08 14:47 +0000
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:30 -0800
        Re: Misleading error message of the day Tim Chase <python.list@tim.thechases.com> - 2011-12-08 11:41 -0600
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:30 -0800
    Re: Misleading error message of the day Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-12-08 16:03 +0100
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:33 -0800
        Re: Misleading error message of the day Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-12-08 20:49 +0100
        Re: Misleading error message of the day Ethan Furman <ethan@stoneleaf.us> - 2011-12-08 12:13 -0800
        Re: Misleading error message of the day Lie Ryan <lie.1296@gmail.com> - 2011-12-09 12:46 +1100
          Re: Misleading error message of the day alex23 <wuwei23@gmail.com> - 2011-12-08 20:57 -0800
            Re: Misleading error message of the day Lie Ryan <lie.1296@gmail.com> - 2011-12-11 10:41 +1100
        Re: Misleading error message of the day Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-12-09 11:03 +0100
          Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-09 09:43 -0500
        Re: Misleading error message of the day Ethan Furman <ethan@stoneleaf.us> - 2011-12-09 09:39 -0800
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:33 -0800
        Re: Misleading error message of the day Grant Edwards <invalid@invalid.invalid> - 2011-12-08 18:10 +0000
          Re: Misleading error message of the day alister <alister.ware@ntlworld.com> - 2011-12-08 20:58 +0000
            Re: Misleading error message of the day Chris Angelico <rosuav@gmail.com> - 2011-12-09 08:17 +1100
          Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 20:19 -0500
          Re: Misleading error message of the day Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-09 02:07 +0000
            Re: Misleading error message of the day Chris Angelico <rosuav@gmail.com> - 2011-12-09 14:46 +1100
              Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 23:44 -0500
    Re: Misleading error message of the day Heiko Wundram <modelnine@modelnine.org> - 2011-12-08 16:16 +0100
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:42 -0800
        Re: Misleading error message of the day Heiko Wundram <modelnine@modelnine.org> - 2011-12-08 16:50 +0100
          Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 10:42 -0800
            Re: Misleading error message of the day Benjamin Kaplan <benjamin.kaplan@case.edu> - 2011-12-08 13:57 -0500
            Re: Misleading error message of the day Ethan Furman <ethan@stoneleaf.us> - 2011-12-08 11:09 -0800
            Re: Misleading error message of the day Benjamin Kaplan <benjamin.kaplan@case.edu> - 2011-12-08 14:38 -0500
            Re: Misleading error message of the day Ethan Furman <ethan@stoneleaf.us> - 2011-12-08 12:09 -0800
          Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 10:42 -0800
        Re: Misleading error message of the day Andrea Crotti <andrea.crotti.0@gmail.com> - 2011-12-08 15:55 +0000
        Re: Misleading error message of the day Chris Angelico <rosuav@gmail.com> - 2011-12-09 03:21 +1100
        Re: Misleading error message of the day Robert Kern <robert.kern@gmail.com> - 2011-12-08 19:57 +0000
      Re: Misleading error message of the day Roy Smith <roy@panix.com> - 2011-12-08 07:42 -0800

Page 2 of 2 — ← Prev page 1 [2]

#16877

On Fri, Dec 9, 2011 at 7:58 AM, alister <alister.ware@ntlworld.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#16887

In article <jbqui9$33c$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> On 2011-12-08, Roy Smith <roy@panix.com> wrote:
> > On Thursday, December 8, 2011 10:03:38 AM UTC-5, Jean-Michel Pichavant 
> > wrote:
> >> string are iterable, considering this, the error is correct.
> >
> > 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
> 
> 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).

[toc] | [prev] | [next] | [standalone]

#16890

On Thu, 08 Dec 2011 18:10:17 +0000, Grant Edwards wrote:

> On 2011-12-08, Roy Smith <roy@panix.com> wrote:
>> On Thursday, December 8, 2011 10:03:38 AM UTC-5, Jean-Michel Pichavant
>> wrote:
>>> string are iterable, considering this, the error is correct.
>>
>> 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
> 
> My favorite is still the old classic error from and old Unix printer
> port driver:
> 
>   "lp0 on fire"
> 
>> but most people would probably agree that it's not the most useful
>> message that could have been produced.

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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#16894

On Fri, Dec 9, 2011 at 1:07 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#16895

In article <mailman.3464.1323402417.27778.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> 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 :-)

[toc] | [prev] | [next] | [standalone]

#16835

Am 08.12.2011 15:47, schrieb Robert Kern:
> Would including the respective numbers help your thought processes?
> ValueError: too many values to unpack (expected 2, got 3)

Not possible in the general case (as the right-hand side might be an 
arbitrary iterable/iterator...).

-- 
--- Heiko.

[toc] | [prev] | [next] | [standalone]

#16840

On Thursday, December 8, 2011 10:16:56 AM UTC-5, Heiko Wundram wrote:
> Am 08.12.2011 15:47, schrieb Robert Kern:
> > Would including the respective numbers help your thought processes?
> > ValueError: too many values to unpack (expected 2, got 3)
> 
> Not possible in the general case (as the right-hand side might be an 
> arbitrary iterable/iterator...).

Why not?  Take this example:

def i():
    i = 0
    while True:
        print "returning:", i
        yield i
        i += 1

a, b = i()

./iter.py
returning: 0
returning: 1
returning: 2
Traceback (most recent call last):
  File "./iter.py", line 10, in <module>
    a, b = i()
ValueError: too many values to unpack

The exception was raised when i() returned it's third value, so saying "expected 2, got 3" is exactly correct.  Yes, it is true that it might have gotten more if it kept going, but that's immaterial; the fact that it got to 3 is what caused the Holy Hand Grenade to be thrown.

[toc] | [prev] | [next] | [standalone]

#16842

Am 08.12.2011 16:42, schrieb Roy Smith:
> The exception was raised when i() returned it's third value, so saying "expected 2, got 3" is exactly correct.  Yes, it is true that it might have gotten more if it kept going, but that's immaterial; the fact that it got to 3 is what caused the Holy Hand Grenade to be thrown.

Please explain how that error message (in case you're not aiming at the 
actual count of elements in the source) differs from the curent wording 
"too many values", as you're simply displaying "expected n, got n+1" 
where n is visible from the immediate exception output...

-- 
--- Heiko.

[toc] | [prev] | [next] | [standalone]

#16858

(some,
 very,
 long,
 list,
 of,
 variable,
 names,
 to,
 get,
 the,
 stuff,
 unpacked,
 into) = function_that_should_return_a_14_tuple()

raises

ValueError: too many values to unpack

Quick, what's the bug?  Did I forget a variable on the LHS, or is my function returning more things than it should?  I know it's supposed to be 14, but I don't know which side is wrong.  Had it said "... expected 13, got 14", I would know immediately.

Error messages should be as explicit as possible.  It's just like bug reports.  The basic mantra of a bug report is:

1) This is what I did

2) This is what I expected to happen

3) This is what I observed happen

4) This is how what I observed differed from what I expected

Saying, "expected X, got Y" is more explicit than "got too many"

[toc] | [prev] | [next] | [standalone]

#16862

On Thu, Dec 8, 2011 at 1:42 PM, Roy Smith <roy@panix.com> wrote:
> (some,
>  very,
>  long,
>  list,
>  of,
>  variable,
>  names,
>  to,
>  get,
>  the,
>  stuff,
>  unpacked,
>  into) = function_that_should_return_a_14_tuple()
>
> raises
>
> ValueError: too many values to unpack
>
> Quick, what's the bug?  Did I forget a variable on the LHS, or is my function returning more things than it should?  I know it's supposed to be 14, but I don't know which side is wrong.  Had it said "... expected 13, got 14", I would know immediately.
>

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.


> Error messages should be as explicit as possible.  It's just like bug reports.  The basic mantra of a bug report is:
>
> 1) This is what I did
>
> 2) This is what I expected to happen
>
> 3) This is what I observed happen
>
> 4) This is how what I observed differed from what I expected
>
> Saying, "expected X, got Y" is more explicit than "got too many"
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#16863

Benjamin Kaplan wrote:
> On Thu, Dec 8, 2011 at 1:42 PM, Roy Smith <roy@panix.com> wrote:
>> (some,
>>  very,
>>  long,
>>  list,
>>  of,
>>  variable,
>>  names,
>>  to,
>>  get,
>>  the,
>>  stuff,
>>  unpacked,
>>  into) = function_that_should_return_a_14_tuple()
>>
>> raises
>>
>> ValueError: too many values to unpack
>>
>> Quick, what's the bug?  Did I forget a variable on the LHS, or is my function returning more things than it should?  I know it's supposed to be 14, but I don't know which side is wrong.  Had it said "... expected 13, got 14", I would know immediately.
>>
> 
> 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~

[toc] | [prev] | [next] | [standalone]

#16864

On Thu, Dec 8, 2011 at 2:09 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> Benjamin Kaplan wrote:
>>
>> On Thu, Dec 8, 2011 at 1:42 PM, Roy Smith <roy@panix.com> wrote:
>>>
>>> (some,
>>>  very,
>>>  long,
>>>  list,
>>>  of,
>>>  variable,
>>>  names,
>>>  to,
>>>  get,
>>>  the,
>>>  stuff,
>>>  unpacked,
>>>  into) = function_that_should_return_a_14_tuple()
>>>
>>> raises
>>>
>>> ValueError: too many values to unpack
>>>
>>> Quick, what's the bug?  Did I forget a variable on the LHS, or is my
>>> function returning more things than it should?  I know it's supposed to be
>>> 14, but I don't know which side is wrong.  Had it said "... expected 13, got
>>> 14", I would know immediately.
>>>
>>
>> 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."
>

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

[toc] | [prev] | [next] | [standalone]

#16872

Benjamin Kaplan wrote:
> On Thu, Dec 8, 2011 at 2:09 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> Benjamin Kaplan wrote:
>>> 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."
>>
> 
> 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~

[toc] | [prev] | [next] | [standalone]

#16859

(some,
 very,
 long,
 list,
 of,
 variable,
 names,
 to,
 get,
 the,
 stuff,
 unpacked,
 into) = function_that_should_return_a_14_tuple()

raises

ValueError: too many values to unpack

Quick, what's the bug?  Did I forget a variable on the LHS, or is my function returning more things than it should?  I know it's supposed to be 14, but I don't know which side is wrong.  Had it said "... expected 13, got 14", I would know immediately.

Error messages should be as explicit as possible.  It's just like bug reports.  The basic mantra of a bug report is:

1) This is what I did

2) This is what I expected to happen

3) This is what I observed happen

4) This is how what I observed differed from what I expected

Saying, "expected X, got Y" is more explicit than "got too many"

[toc] | [prev] | [next] | [standalone]

#16843

On 12/08/2011 03:42 PM, Roy Smith wrote:
>
> Why not?  Take this example:
>
> def i():
>      i = 0
>      while True:
>          print "returning:", i
>          yield i
>          i += 1
>
> a, b = i()
>
> ./iter.py
> returning: 0
> returning: 1
> returning: 2
> Traceback (most recent call last):
>    File "./iter.py", line 10, in<module>
>      a, b = i()
> ValueError: too many values to unpack
>
> The exception was raised when i() returned it's third value, so saying "expected 2, got 3" is exactly correct.  Yes, it is true that it might have gotten more if it kept going, but that's immaterial; the fact that it got to 3 is what caused the Holy Hand Grenade to be thrown.

Yes but how do you know how many values you generated when it quits?
I mean I don't know how it work internally, but it should keep a temporary
list of the yielded values to be able to find out how many values are 
there..

[toc] | [prev] | [next] | [standalone]

#16844

On Fri, Dec 9, 2011 at 2:55 AM, Andrea Crotti <andrea.crotti.0@gmail.com> wrote:
> Yes but how do you know how many values you generated when it quits?
> I mean I don't know how it work internally, but it should keep a temporary
> list of the yielded values to be able to find out how many values are
> there..

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.

ChrisA

[toc] | [prev] | [next] | [standalone]

#16868

On 12/8/11 4:21 PM, Chris Angelico wrote:
> On Fri, Dec 9, 2011 at 2:55 AM, Andrea Crotti<andrea.crotti.0@gmail.com>  wrote:
>> Yes but how do you know how many values you generated when it quits?
>> I mean I don't know how it work internally, but it should keep a temporary
>> list of the yielded values to be able to find out how many values are
>> there..
>
> 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

[toc] | [prev] | [next] | [standalone]

#16841

On Thursday, December 8, 2011 10:16:56 AM UTC-5, Heiko Wundram wrote:
> Am 08.12.2011 15:47, schrieb Robert Kern:
> > Would including the respective numbers help your thought processes?
> > ValueError: too many values to unpack (expected 2, got 3)
> 
> Not possible in the general case (as the right-hand side might be an 
> arbitrary iterable/iterator...).

Why not?  Take this example:

def i():
    i = 0
    while True:
        print "returning:", i
        yield i
        i += 1

a, b = i()

./iter.py
returning: 0
returning: 1
returning: 2
Traceback (most recent call last):
  File "./iter.py", line 10, in <module>
    a, b = i()
ValueError: too many values to unpack

The exception was raised when i() returned it's third value, so saying "expected 2, got 3" is exactly correct.  Yes, it is true that it might have gotten more if it kept going, but that's immaterial; the fact that it got to 3 is what caused the Holy Hand Grenade to be thrown.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web