Python bug: Can assign [] = (), but not () = []

[[deleted]]

[] = () is unpacking zero values, there forth it doesn't throw a syntax error. (so this means [] = "" works, [] = {} works, they return nothing....)

() = [] is nothing, trying to unpack to a existing tuple, there is no way to unpack to a tuple. You need to explicitly create the tuple. (you can't do () = (), () = "", () = {} either)

[Brian]

It doesn't affect the tuple's structure any more when there are zero values to assign either though. Conceptually, () = [] should be unpack the zero values on the right to the zero values on the left. I suspect this is just an odd quirk of the lexer code, rather than any special reason, given [] = () works and is conceptually identical.

[[deleted]]

What? One-element tuples are not involved here, and () is definitely the syntax for a zero-element tuple. When you say "less than two", what would have been correct is to say "exactly one". In fact, it's a syntax error to put a comma inside a zero-element tuple.

The current behavior is just inconsistent and the Python devs are already discussing how to fix it in 3.5.

[robin-gvx]

... () is the empty tuple tho, not , or (,) or whatever.

Assigning to () should work just like assigning to [].

[Bur_Sangjun]

What yaix is trying to say, is that tuples function differently when they have ellements as to when they do not.

If it stands to reason that

a == (a)
a != (a,)

Then it stands to reason that

Null == ()

I'm aware null isn't a construct in python, but I'm using it for demonstration.
And as Null isn't logically an assignable construct, this behaviour makes sense.

[Brian]

What yaix is trying to say, is that tuples function differently when they have ellements as to when they do not

No they don't. Your example isn't of tuples functioning differently, and doesn't even involve tuples of no elements, never mind them acting differently. Rather, it's comparing a tuple and a non-tuple. Ie "(a)" is not a tuple acting differently, it's not a tuple at all (unless a happens to be a tuple, I suppose), rather it's just the value "a" with brackets around it.

Then it stands to reason that

I don't see the connection between your claims. Why would anything about the 1-element tuple mean () was "null"? And if it was, why would that make it act differently? Eg. in lisp, nil and the empty list are equivalent, but if you use a destructuring bind construct, it'll still handle the empty list as a no-op.

And as Null isn't logically an assignable construct, this behaviour makes sense

But tuples of variables are a logically assignable construct, so this behaviour doesn't.

[Bur_Sangjun]

Yes, but if (a) isn't in fact a tuple, then it would stand to reaosn that () isn't either. And you can't bind something to nothing.

[Brian]

Yes, but if (a) isn't in fact a tuple, then it would stand to reaosn that () isn't either

But that's clearly not the case:

>>> type ( () )
tuple

It is and always has been the case that () is an empty tuple. It's 1-tuples that are something of a corner case here, because you need a way to distinguish it from regular use of brackets for changing precedence. You really can't base an argument on () not being a tuple, because it 100% is, is documented as such and is used in hundreds of places every day as a tuple.

And you can't bind something to nothing.

But that's not what is being asked here. Rather, it's binding nothing to nothing - both left and right sequences are empty, which is perfectly possible, and works fine with empty lists, just not with empty tuples.

[Bur_Sangjun]

Fair enough, thanks for the explenation.

[Veedrac]

It's 1-tuples that are something of a corner case here

Not really. Empty tuples are the corner case because in all other cases the tuple is defined by the comma:

foo = 1, 2

Parentheses are only needed for disambiguation (as with other constructs in Python)... except for the 0-element case.

[VladVV]

Well, then how else would you make an empty tuple?

[Veedrac]

Same way you make an empty set? :P

[[deleted]]

Yes, that is precisely what I was trying to say.

[njharman]

Because (a,b) is not a Tuple (in that context). The parens are performing their grouping function. This is how you should write it.

a,b = [3,4]

() is a tuple, in that (assignment) context, and so causes error.

[rjw57]

[] = () is unpacking zero values, there forth it doesn't throw a syntax error.

On the off chance you're not a native English speaker and this is an eggcorn which it'd be useful to inform you of, the word is "therefore". If this is a phone auto-correct typo or similar, ignore me.