Home Original page

error messages raised by python got me thinking.

Laura Creighton lac at strakt.com
Mon Oct 22 06:51:58 EDT 2001 
Thank you very much for your reply.

I would greatly prefer "cannot concatenate 'string' and '%s'".  Am I being
a pedant for wanting "cannot concatenate instances of 'string' and '%s'"?
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_...)

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

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

As for:
>     "unsupported operand type for +: 'int' and 'str'"

      Typo, you meant "unsupported operand _types_,"  correct?
> 
> (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: ".

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:

"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?  

Thank you again,
Laura Creighton
More information about the Python-list mailing list