Guido van Rossum wrote:
When we changed floats to behave different on repr() than on str(), we briefly discussed changes to the container objects as well, but nothing came of it.
Currently, str() of a tuple, list or dictionary is the same as repr() of those objects. This is not very consistent. For example, when we have a float like 1.1 which can't be represented exactly, str() yields "1.1" but repr() yields "1.1000000000000001". But if we place the same number in a list, it doesn't matter which function we use: we always get "[1.1000000000000001]".
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.
Is it too late to check this in? Another negative consequence would be that for user-defined or 3rd party extension objects that have different repr() and str(), like NumPy arrays, it might break some code -- but I think this is not very likely.
-1 I don't think that such a change is really worth breaking code which relies on the current output of repr(list) or str(list). As the test script from Fredrik for the Unicode database showed there are some very subtle implications to changes in str() and repr() -- e.g. in the mentioned case the hash value would change. Also, if I understand the patch correctly, str(list) would be almost the same as '[' + ', '.join(map(str, entries)) + ']' and '[' + ', '.join(map(repr, entries)) + ']' for repr(). While this may seem more transparent, I think it will cause problems in practice: e.g. for large data buffers, str(list) would now return the contents of the buffers rather than just an abstract note about a buffer containing the memory mapped data of file xyz.txt. As consequence, you'd suddenly get a few MBs of output instead of a 100 char string... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/