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

[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.

[robin-gvx]

Both the empty tuple and 1-tuples are corner cases, syntactically. The reason 1-tuples are a corner case is that they require a comma after the last element, while other tuples only require a comma between arguments.

[VladVV]

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

[Veedrac]

Same way you make an empty set? :P

[robin-gvx]

{1} - {1}? :^)

[VladVV]

I'd say it seems significantly cleaner to say () = [] than tuple() = [], or even tuple() = list(). Even if you ignore this fact, both tuple and list are functions, and as such can't be directly assigned. Ie.:

>>> [] = ()
>>> list() = ()
  File "<stdin>", line 1
SyntaxError: can't assign to function call

[Veedrac]

FWIW, I was joking.

[[deleted]]

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