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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4