Tim Peters wrote:
[Andrew Kuchling]
Is it OK to refer to 8-bit strings under that name? How about "expected an 8-bit string or Unicode string", when the object passed to ord() isn't of the right type.
Similarly, when the value is of the right type but has length>1, the message is "ord() expected a character, length-%d string found". Should that be "length-%d (string / unicode) found)"
And should the type names be changed to '8-bit string'/'Unicode string', maybe?
Actually, upon reflection I think it was a mistake to add all these "or Unicode" clauses to the error msgs to begin with. Python used to have only one string type, we're saying that's also a hope for the future, and in the meantime I know I'd have no trouble understanding "string" as including both 8-bit strings and Unicode strings.
So we should say "8-bit string" or "Unicode string" when *only* one of those is allowable. So
"ord() expected string ..."
instead of (even a repaired version of)
"ord() expected string or Unicode character ..."
I think this has to do with understanding that there are two string types in Python 2.0 -- a novice won't notice this until she sees the error message. My understanding is similar to yours, "string" should mean "any string object" and in cases where the difference between 8-bit string and Unicode matters, these should be referred to as "8-bit string" and "Unicode string". Still, I think it is a good idea to make people aware of the possibility of passing Unicode objects to these functions, so perhaps the idea of adding both possibilies to error messages is not such a bad idea for 2.1. The next phases would be converting all messages back to "string" and then convert all strings to Unicode ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/