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