[Python-Dev] Changes in semantics to str()?

M.-A. Lemburg mal@lemburg.com
Mon, 02 Oct 2000 09:51:37 +0200

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.


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/