Differentiate LvalueTuple from expression TupleExpr (refactoring)

[elazarg]

(Apologies in advance if I am explaining the obvious)
In the expression

(a, b) = (b, a)

The left side is an lvalue and the right side is not. The two concepts have only so much in common. If a TupleExpr makes its way where an LvalueTuple belongs, that's a bug. It's also a bug in the other way around (unlike in some programming languages). This distinction appears in the AST as a Load/Store distinction, and it should be expressed in node.py too.

This distinction needs to be accompanied with the general distinction of lvalue nodes (i.e. a dedicated unifying type, instead of a comment) for targets in for, with etc.. However, I don't think that a dedicated LvalueName is helpful since it refers to the same entity as NameExpr. It is not the case with tuples; LvalueTuple is more of a pattern-matching construct than an expression.

The should not be a distinction between LvalueTuple and LvalueList. since the language does not have this distinction (e.g. [a, b] = (b, a) is valid)

I think that it will make the code clearer, better documented, better checked and with less isinstance tests and casts sprinkled around; in some cases, I think that these tests will be replace by an accept() call.

[elazarg]

Related: Issue #1783, PR #1785, PR #2121 and PR #2122

[gvanrossum]

Can you hold your horses a bit here? I'd like to see the need for this refactoring demonstrated by a specific feature that you currently find complicated to implement, rather than just say it's "better" (the ultimate subjective measure, IMO).

[gvanrossum]

Let's just close this since we didn't ask for this refactoring.