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 1 of 2  [1] 2  Next page →

#16829 — Misleading error message of the day

I just spent a while beating my head against this one.

# Python 2.6
>>> a, b = 'foo'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack

The real problem is that there's too *few* values to unpack!  It should 
have been

a, b = 'foo', 'bar'

I understand why it's generating the exception it does (the string is an 
iterable), but man, did that message throw off my thought processes and 
lead me down some totally bogus debugging paths.

It's an unusual case to want to unpack a string.  Maybe the message 
should changed to "too {many, few} values to unpack (are you sure you 
wanted to unpack a string?)" if the RHS is a basestring?

[toc] | [next] | [standalone]

#16830

On 12/08/2011 02:23 PM, Roy Smith wrote:
> I just spent a while beating my head against this one.
>
> # Python 2.6
>>>> a, b = 'foo'
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> ValueError: too many values to unpack
>
> The real problem is that there's too *few* values to unpack!  It should
> have been
>
> a, b = 'foo', 'bar'
>
> I understand why it's generating the exception it does (the string is an
> iterable), but man, did that message throw off my thought processes and
> lead me down some totally bogus debugging paths.
>
> It's an unusual case to want to unpack a string.  Maybe the message
> should changed to "too {many, few} values to unpack (are you sure you
> wanted to unpack a string?)" if the RHS is a basestring?

I had a few errors sometimes because I thought I passed in a list while
I passed only a string, which since it's still iterable would just work
but explode later.

A nicer message wouldn't have really actually helped though, not sure
it's worth to make an exception for such a thing..

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

#16831

On Fri, Dec 9, 2011 at 1:23 AM, Roy Smith <roy@panix.com> wrote:
> I just spent a while beating my head against this one.
>
> # Python 2.6
>>>> a, b = 'foo'
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> ValueError: too many values to unpack

Definitely weird! I smell a job for a linter though. If you had just
happened to have a two-character string there, it would have quietly
succeeded, and left you wondering what was going on - imho rather
worse.

This isn't something for the language to solve; the same issue would
come up if you had something like:

a=[1,2,3]
b=[4,5,6]

c,d=a # oops, mucked up the "a,b" side

Or any other iterable. Looks to me like a chance for an informational
note from your lint facility, not a change to the language.

ChrisA

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

#16832

On 12/8/11 2:23 PM, Roy Smith wrote:
> I just spent a while beating my head against this one.
>
> # Python 2.6
>>>> a, b = 'foo'
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> ValueError: too many values to unpack
>
> The real problem is that there's too *few* values to unpack!  It should
> have been
>
> a, b = 'foo', 'bar'
>
> I understand why it's generating the exception it does (the string is an
> iterable), but man, did that message throw off my thought processes and
> lead me down some totally bogus debugging paths.
>
> It's an unusual case to want to unpack a string.  Maybe the message
> should changed to "too {many, few} values to unpack (are you sure you
> wanted to unpack a string?)" if the RHS is a basestring?

Would including the respective numbers help your thought processes?

ValueError: too many values to unpack (expected 2, got 3)

-- 
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]

#16836

On Thursday, December 8, 2011 9:47:02 AM UTC-5, Robert Kern wrote:

> Would including the respective numbers help your thought processes?
> 
> ValueError: too many values to unpack (expected 2, got 3)

I don't know if that would have done the trick for me on this particular one.  On the other hand, adding "expected X, got Y" to the  message would generally be a good thing.

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

#16855

On 12/08/11 09:30, Roy Smith wrote:
> On Thursday, December 8, 2011 9:47:02 AM UTC-5, Robert Kern
> wrote:
>
>> Would including the respective numbers help your thought
>> processes?
>>
>> ValueError: too many values to unpack (expected 2, got 3)
>
> I don't know if that would have done the trick for me on this
> particular one.  On the other hand, adding "expected X, got Y"
> to the  message would generally be a good thing.

given the nature of the message, and the interaction with 
iterators-of-arbitrary/infinite length, it might have to be 
reduced to

   "Expected N, got more"

or for the case where you didn't get enough, you know how many 
you got: "Expected N, but only got M".  But the extra information 
would certainly be useful in tracking it down.

-tkc

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

#16837

On Thursday, December 8, 2011 9:47:02 AM UTC-5, Robert Kern wrote:

> Would including the respective numbers help your thought processes?
> 
> ValueError: too many values to unpack (expected 2, got 3)

I don't know if that would have done the trick for me on this particular one.  On the other hand, adding "expected X, got Y" to the  message would generally be a good thing.

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

#16833

Roy Smith wrote:
> I just spent a while beating my head against this one.
>
> # Python 2.6
>   
>>>> a, b = 'foo'
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: too many values to unpack
>
> The real problem is that there's too *few* values to unpack!  It should 
> have been
>
> a, b = 'foo', 'bar'
>
> I understand why it's generating the exception it does (the string is an 
> iterable), but man, did that message throw off my thought processes and 
> lead me down some totally bogus debugging paths.
>
> It's an unusual case to want to unpack a string.  Maybe the message 
> should changed to "too {many, few} values to unpack (are you sure you 
> wanted to unpack a string?)" if the RHS is a basestring?
>   
string are iterable, considering this, the error is correct.

Values to unpack in 'foo' are 'f', 'o', 'o'

 > a,b,c = 'foo'

 > print a,b,c
f o o


JM

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

#16838

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

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

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

#16865

Roy Smith 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
>
> 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 :o) 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

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

#16869

Jean-Michel Pichavant wrote:
> You have to opportunity to not use unpacking anymore :o) 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~

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

#16888

On 12/09/2011 07:13 AM, Ethan Furman wrote:
> Jean-Michel Pichavant wrote:
>> You have to opportunity to not use unpacking anymore :o) 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?

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

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

#16896

On Dec 9, 11:46 am, Lie Ryan <lie.1...@gmail.com> wrote:
> 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'?

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

#16970

On 12/09/2011 03:57 PM, alex23 wrote:
> On Dec 9, 11:46 am, Lie Ryan<lie.1...@gmail.com>  wrote:
>> 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'?

Ah, yes I do

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

#16904

Ethan Furman wrote:
> Jean-Michel Pichavant wrote:
>> You have to opportunity to not use unpacking anymore :o) 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~
"A tuple in order to pass returned values ?" was the thread.

JM

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

#16914

In article <mailman.3466.1323425036.27778.python-list@python.org>,
 Jean-Michel Pichavant <jeanmichel@sequans.com> wrote:

> Ethan Furman wrote:
> > Jean-Michel Pichavant wrote:
> >> You have to opportunity to not use unpacking anymore :o) 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~
> "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

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

#16927

Jean-Michel Pichavant wrote:
> Ethan Furman wrote:
>> Jean-Michel Pichavant wrote:
>>> You have to opportunity to not use unpacking anymore :o) 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~
> "A tuple in order to pass returned values ?" was the thread.

Thanks.

~Ethan~

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

#16839

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

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

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

#16857

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.

-- 
Grant Edwards               grant.b.edwards        Yow! Don't hit me!!  I'm in
                                  at               the Twilight Zone!!!
                              gmail.com            

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

#16874

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.

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




-- 
"I once witnessed a long-winded, month-long flamewar over the use of
mice vs. trackballs...It was very silly."
(By Matt Welsh)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web