str() should convert ANY object to a string without EXCEPTIONS !

Steven D'Aprano steve at
Sun Sep 28 10:26:33 CEST 2008

On Sun, 28 Sep 2008 03:55:46 -0400, Terry Reedy wrote:

> est wrote:
>>>From python manual
>> str( [object])
>> Return a string containing a nicely printable representation of an
>> object. For strings, this returns the string itself. The difference
>> with repr(object) is that str(object) does not always attempt to return
>> a string that is acceptable to eval(); its goal is to return a
>> printable string. If no argument is given, returns the empty string,
>> ''.
>> now we try this under windows:
>>>>> str(u'\ue863')
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\ue863' in
>> position 0
>> : ordinal not in range(128)
> In 3.0 this is fixed:
>>>> str('\ue863') # u prefix is gone
> '\ue863'
>>>> str(b'123') # b prefix is added
> "b'123'"
> Problems like this at least partly motivated the change to unicode
> instead of bytes as the string type.

I'm not sure that "fixed" is the right word. Isn't that more or less the 
same as telling the OP to use unicode() instead of str()? It merely 
avoids the problem of converting Unicode to ASCII by leaving your string 
as Unicode, rather than fixing it. Perhaps that's the right thing to do, 
but it's a bit like the old joke:

"Doctor, it hurts when I do this."
"Then don't do it!"

As for the second example you give:

>>> str(b'123') # b prefix is added

Perhaps I'm misinterpreting it, but from here it looks to me that str() 
is doing what repr() used to do, and I'm really not sure that's a good 
thing. I would have expected that str(b'123') in Python 3 should do the 
same thing as unicode('123') does now:

>>> unicode('123')

(except without the u prefix).


More information about the Python-list mailing list