On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote:
Below I have included changes to listobject.c, tupleobject.c and dictobject.c that fix this. The fixes change the print and str() callbacks for these objects to use PyObject_Str() on the contained items -- except if the item is a string or Unicode string. I made these exceptions because I don't like the idea of str(["abc"]) yielding [abc] -- I'm too used to the idea of seeing ['abc'] here. And str() of a Unicode object fails when it contains non-ASCII characters, so that's no good either -- it would break too much code.
Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for
some lunch/breakfast ;) I would be in favor if the str() output were only
used to display something to a user, but that's not the case. And too many
people are under the impression that the 'print' handler is the same as the
'str' handler to make that distinction now, I'm afraid. My main gripe with
this change is that it makes str() for container objects unreliable...
Strings are a special case, but class-instances are not -- so something like
UserString will be displayed without quotes. I don't like the idea of
sometimes doing 'str' and sometimes doing 'repr'.
I understand what it's trying to solve, but I don't think that's a worse
inconsistency than the one this change introduces. It's also easy to
explain: 'str(list or dict) is the same as repr(list or dict)'. The new
phrase would be something like 'str(list or dict) calls str() on the objects
it contains, except for string and unicode objects.'. And even that breaks
when you mix in instances that wrap a container. A list containing a
UserList containing a set of (unicode-)strings would display the strings
without quotes. And you can't see that the second container is a UserList.
I also don't think this change should be made between the final beta and
2.0. Jeremy, don't let him ruin your feature freeze! :-)
--
Thomas Wouters