[Python-ideas] reprs of recursive datastructures.
Guido van Rossum
guido at python.org
Sat Sep 8 11:49:29 CEST 2012
On Sat, Sep 8, 2012 at 9:17 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 9/8/2012 2:27 AM, Guido van Rossum wrote:
>> Can someone explain what problem we are trying to solve? I fail to
>> uderstand what's wrong with the current behavior...
> Pairs of different things have the same representation, making the
> representation ambiguous to both people and the interpreter.
Well yeah, when designing a repr() we usually have to compromise. E.g.
if you render a class instance it often shows the class name but not
the module name (e.g. decimal.Decimal.)
> Moreover, the interpreter's guess is usually wrong.
The requirement that the interpreter can evaluate a repr() and return
a similar value is pretty weak, and I'm not sure that in this case the
fact that copying the output back into the interpreter returns an
object of a different share matters much to anyone.
A subtler but similar bug appears with lists containing multiple
references to the same sublist, e.g.
>>> a = [1, 2]
>>> b = [a, a]
[[1, 2], [1, 2]]
[[1, 2, 3], [1, 2, 3]]
>>> x = [[1, 2], [1, 2]]
[[1, 2, 3], [1, 2]]
I don't think we should attempt to fix this particular one -- first of
all, the analysis would be tricky (there could be a user-defined
object involved) and second of all, I can't think of a solution that
still produces a valid expression (except perhaps a very ugly one).
> In particular, the representations of recursive lists use what is now the
> Ellipsis literal '...', so they are also valid list displays for a
> non-recursive nested list containing Ellipsis. The interpreter always reads
> ... as the Ellipsis literal, which it nearly always is not what is meant.
But when does it ever matter?
> It would be trivial to tweak the representations of recursive lists so they
> are not valid list displays.
To what purpose? I still don't understand what the actual use case is
where you think that will produce a better experience for the user.
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas