error messages raised by python got me thinking.

[Guido van Rossum]

Laura Creighton <lac at strakt.com> writes:

> Thank you very much for your reply.

You're welcome.  I am always to make Python better -- and this was an
easy fix!

> I would greatly prefer "cannot concatenate 'string' and '%s'".  Am I being
> a pedant for wanting "cannot concatenate instances of 'string' and '%s'"?

No -- I noticed that myself and checked in "cannot concatenate 'str'
and '%s' objects".

> or, since 'str' is the way of the future, "cannot concatenate instances 
> of 'str' and '%s'"? (I'd like uniformity across error messages whenever
> possible, so unless you want to start referring to ints as _integers_...)

I am hoping to reserve the term 'integer' for the unified concept.

> > But in general, we can't always produce the error message you'd like
> > to see: e.g. if you try to add a Unicode string and a number, you get
> > the even less clear
> > 
> >     TypeError: coercing to Unicode: need string or buffer, int found
> > 
> > This one is hard to fix, due to the complicated logic attempted in the
> > Unicode case (the code that issues the error message has no idea that
> > it is part of a '+' operator).
> 
> I understand.  Is the information about the _position_ of the
> argument that fails long gone as well?
> 
> 	lac at ratthing-b246:~/src/pynche/newpynche$ python -U
> 	Python 2.1 (#3, May 26 2001, 17:43:53) 
> 	[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
> 	Type "copyright", "credits" or "license" for more information.
> 	>>> f='1'
> 	>>> g=2
> 	>>> f+g
> 	Traceback (most recent call last):
>   	File "<stdin>", line 1, in ?
> 	TypeError: coercing to Unicode: need string or buffer, int found
> 
> What I want to know, is that it is my _second_ argument that is wrong.
> (Without remembering that if my first one was bad, I would be getting
> the 'unsupported operand types for +' message.)  This is more important
> when you are doing things like this:
> 
> 	>>> h='3'
> 	>>> i='4'
> 	>>> f+h+g+i
> 	Traceback (most recent call last):
>   	File "<stdin>", line 1, in ?
> 	TypeError: coercing to Unicode: need string or buffer, int found
> 
> (at least _my_ little voice says: 'which _one_, damnit!!'  <Your little
> voice may be a lot politer than mine.>)  Would this be possible?

Alas, not very easy.  The solution here, unfortunately, will probably
have to be sought in a smarter debugger that shows tha values of all
variables referenced in a line.

> 	>>> f+h+g+i
> 	Traceback (most recent call last):
>   	File "<stdin>", line 1, in ?
> 	TypeError: coercing to Unicode: need string or buffer: int found at position 3  # I just made this up

Sorry, this is not realistic given the way the interpreter works.
Besides, in a situation like

  f(x+y+z, a*b*c*d, p**q**r)

what would "position 3" refer to?

> Note, I changed the comma after _buffer_ to a colon when I added the 
> theoretical position information, for consistency in punctuation between 
> this error and the "unsupported operand types[sic] for +:" error, discussed
> next.

That's a nice idea.

> As for:
> >     "unsupported operand type for +: 'int' and 'str'"
> 
>       Typo, you meant "unsupported operand _types_,"  correct?

Yes.

> > (It would have to be 'str' because as of 2.2, that's the name for the
> > string object type, corresponding to the function most commonly used
> > to create strings.)
> > 
> > Another way to write this, using 2.2 lingo, might be
> > 
> >     "unsupported operand types: int() + str()"
> > 
> > but this doesn't look very newbie-friendly to me!
> 
> I think that it is important to list what operation failed, so
> "unsupported operand types for +:" or (my preference) 
> "unsupported operand types for '+':" is better than the less informative
> "unsupported operand types: ".

Yes.  Note that the operator still appeared in the message, between
int() and str(). :-)

> But whether to use
> "'int' and 'str'" or "int() and str()" is a different question.  My
> initial reaction is to prefer "int() and str()", I think because it
> perfectly jogs your memory about how to _fix_ your error.  So, were
> it my decision, I would let it rattle about in my head for a week
> or so, and then, if I still liked it I would go with:

Hm, a week from now this will long be gone from my brain. :-)  Today,
think that for a newbie, int() just has two mysterious parentheses,
and for an expert, it's at best cute to know that you can type this:

    >>> int() + str()
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: unsupported operand types for +: 'int' and 'str'
    >>> 

> "unsupported operand types for '+': int() and str()".
> 
> Of course, if my suggestion for listing the position of the 
> argument that triggered the failed unicode conversion error makes it
> into a python release, you may want the following for consistency:
> 
> 	>>> g+f+h+i
> 	Traceback (most recent call last):
>   	File "<stdin>", line 1, in ?
> 	TypeError: unsupported operand types for '+': int() and str() found at positions 1 and 2 
> 
> Is this the sort of thing that should get a PEP?  

Not really -- it doesn't change the language, it's what would be
called a "quality of implementation" issue.  If it said

    "TypeError: oomph"

it would still be Python. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)