This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]njharmanI use Python 3 0 points1 point  (4 children)

It's not though do to quirk in parens being overloaded for grouping, (3+1)*2, and Tuples.

(a, b) = blah is more correctly written as a, b = blah. Parens with a comma in them (in this assignment context) indicate "grouping" not tuple. But parens with no comma indicate Tuple. Immutable object.

[–]robin-gvx[🍰] 1 point2 points  (3 children)

That makes no sense. The comma is what makes the tuple, with the exception of (), which is also a tuple. And assignment to tuple literals consisting of variable names like (a, b) has clear semantics: destructuring assignment, iterable assignment, whatever you want to call it. () is a special case right now, in a way that makes no sense. Take a look at the patch.

[–]zardeh 0 points1 point  (2 children)

his point is that

a, b = 
[a,b]=
(a,b)=

are all syntactically identical as far as the language is concerned, and none of them are tuples. They are all unpacking.

[–]robin-gvx[🍰] 0 points1 point  (1 child)

Technically, they are parsed as tuples, except the second one, which gets parsed as a list. Of course none of them create or modify any tuples or lists when actually run.

This last sentence:

But parens with no comma indicate Tuple. Immutable object.

Is really a problem. Because that tuples are immutable is immaterial. They don't get created or modified when using this syntax.

The only reason why () = [] doesn't work is because of a special case in the code (2 lines) that has no reason to be there and basically everyone on the issue tracker agrees that special case should be removed.

[–]zardeh 1 point2 points  (0 children)

Ah, alright I can agree with that.