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

This contradicts the assignment grammar, which would make both illegal: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements

My guess is that it is not worth complicating the parser in order to make these two cases consistent, and it should be treated as a doc error. We'll see what other developers think.

The starting point is recognizing that this has been around for very long time and is harmless.

It seems that assigning to [] is the odd one out in this case. Why is this even possible?

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

But () is the odd one out if you consider

>>> [a, b] = range(2)
>>> [] = range(0)
>>> (a, b) = range(2)
>>> () = range(0)
  File "<stdin>", line 1
SyntaxError: can't assign to ()

In ast.c, set_context checks for assignment to an empty tuple, but not an empty list.

        case List_kind:
            e->v.List.ctx = ctx;
            s = e->v.List.elts;
            break;
        case Tuple_kind:
            if (asdl_seq_LEN(e->v.Tuple.elts))  {
                e->v.Tuple.ctx = ctx;
                s = e->v.Tuple.elts;
            }
            else {
                expr_name = "()";
            }
            break;

https://hg.python.org/cpython/file/ab2c023a9432/Python/ast.c#l912

As Raymond notes, this is a fairly harmless quirk - it changes a SyntaxError to an iterable length dependent ValueError:

>>> () = []
  File "<stdin>", line 1
SyntaxError: can't assign to ()
>>> [] = ()
>>> [] = [1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack (expected 0)

I only found out about this after being puzzled when a typo in a live demo at PyCon 2015 failed to fail as I expected after seeing the presenter type a "[]" into the LHS of an assignment instead of the intended "_".

Removing the data dependence to make the assignment fail immediately (even if never tested against a non-empty iterable) would involve making the handling of List_kind match that of Tuple_kind in the switch statement that eryksun quoted.

I don't think it's an urgent fix, but if someone wanted to fix it (including a new test), I think it would be a reasonable contribution to accept.

I would prefer this be fixed in the opposite direction, to allow “unpacking” an empty iterable using round brackets. I have used this syntax on purpose as a concise way to ensure that a generator is exhaused with no more yields:

>>> def gen():
...     yield "partial computation"
...     print("computation allowed to complete")
... 
>>> g = gen()
>>> next(g)
'partial computation'
>>> [] = g
computation allowed to complete

There is also no reason to break currently working code, which turning this into a syntax error would od.

There is also no reason to break currently working code

Agreed. To take one example, David Beazley's PyCon 2015 talk would have been broken by the suggested change! (See https://www.youtube.com/watch?v=MCs5OvhV9S4, at around the 42:17 mark.)

If there's any code change resulting from this issue, I also think it should be to make assignment to () legal.

I don't have a strong opinion on this, but here is a patch to make () = [] a valid assignment.

About the patch: I'm sure there are other tests to change,
in test_syntax.py for example::

It's a syntax error to assign to the empty tuple.  Why isn't it an
error to assign to the empty list?  It will always raise some error  at
runtime.

    >>> () = 1
    Traceback (most recent call last):
      File "<doctest test.test_syntax[3]>", line 1
    SyntaxError: can't assign to ()

isn't it logical?

[] is a mutable data structure
while () is a immutable data structure

(b, a) = [1, 2] is fine because a and b are mutable

[a, b] = (1, 2) is also fine.

I prefer to unpack into square brackets in general because it is a mnemonic for the star argument being a list:

>>> (a, *b) = range(3)
>>> a
0
>>> b  # A list, even though it was unpacked using tuple-like syntax
[1, 2]

Berker's patch looks good.
It has several virtues:

• the error message is reasonable and clear
• it makes the language more consistent
• it doesn't break any existing code.
• it makes the AST a little simpler and faster
  by removing a special case

The patch needs to updated:

• remove the whatsnew entry
• fix test_codeop which expects "del ()" to raise SyntaxError
• fix test_syntax which fails on "() = 1" and "del ()"
• fix test_with which fails on "with mock as ()"

isn't it logical?

[] is a mutable data structure
while () is a immutable data structure

but you don’t assign to data structures, but to names. you *modify* data structures. and in the square bracket assignment syntax you don’t modify the list created by the []. in fact the [] never even create a list.

—————————————————————————————

also it’s news to me that [a, b] = range(2) works!

i always did a, b = range(2), and knew that (a, b) = range(2) works.

but assigning to something looking like a list literal is new and surprising to me. (and i thought i’ve mastered every corner of python’s syntax)

+1 for Martin's suggestion of removing the inconsistency the other way (i.e. allowing "() = iterable" to mean the same thing as "[] = iterable", effectively asserting that an iterable is empty)

I also agree with Raymond that it doesn't need to be mentioned in the What's New doc, just in the NEWS file.

Thanks for the reviews. Here is an updated patch.

I welcome this patch to go ahead. But the documentation <https://docs.python.org/3.6/reference/simple_stmts.html#assignment-statements\> also needs updating (see original post). I think it should mention that “target_list” can be empty. And it should use “iterable” instead of “sequence” in more places.

Martin, do you want to take it from here?

I missed Martin's comment about the documentation. I will update my patch.

Okay I’ll let Berker update his patch, but I’m happy to try my hand at updating the documentation if needed.

I reviewed the current patch. I can’t say whether the ast.c change is good or not. But IMO the test would be better off in somewhere like /Lib/test/test_unpack.py. It is only a superficial relationship with tuples because the syntax looks the same. Also may be worth testing that [] = [] etc work as well.

Here is an updated patch. I moved the test into test_unpack and added additional tests. sequence -> iterable changes should probably be applied to 3.5 as well.

Thanks for the review, Martin.

Erm, I think you went overboard with the sequence → iterable changes and subscripting; see the review. Also, I think target_list should be made optional in the grammar description.

Hi Berker. I updated your patch according to my comments in the documentation. I hope you don’t mind.

I reverted all the changes about subscripting and slicing an iterable, since this bug is only about assigning to a “target list”.

Actually it is true (despite the current documentation) that you can often assign

sequence[slice] = iterable

But I think that is a separate problem.

New changeset 8a0754fed986 by Berker Peksag in branch 'default':
Issue bpo-23275: Allow () = iterable assignment syntax
https://hg.python.org/cpython/rev/8a0754fed986

Thanks Martin. Your edits look much better! :) I will be travelling for PyCon US later this week so I just committed issue23275_v4.diff with minor edits.

New changeset d3a75daf61e1 by Martin Panter in branch 'default':
Issue bpo-23275: Don’t think this made it into alpha 1
https://hg.python.org/cpython/rev/d3a75daf61e1

I just moved the NEWS entry under the alpha 2 heading.

For patches I am going to commit myself, I usually write the NEWS beforehand and remember to adjust it when committing. But perhaps I shouldn’t have done that in this case :)

New changeset 39a72018dd76 by Martin Panter in branch '3.5':
Issue bpo-23275: Backport target list assignment documentation fixes
https://hg.python.org/cpython/rev/39a72018dd76

New changeset 8700f4d09b28 by Martin Panter in branch '2.7':
Issue bpo-23275: Backport empty square bracket assignment documentation fix
https://hg.python.org/cpython/rev/8700f4d09b28