On Sat, Sep 8, 2012 at 9:17 AM, Terry Reedy 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] b [[1, 2], [1, 2]] b[0].append(3) b [[1, 2, 3], [1, 2, 3]] x = [[1, 2], [1, 2]] x[0].append(3) x [[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)