Since the time 'x in set' optimization was added to peephole it has the following bug with set unpacking:

>>> def foo(x,y):
	a,b = {x,y}
	return a,b

>>> dis(foo)
  2           0 LOAD_FAST                0 (x) 
              3 LOAD_FAST                1 (y) 
              6 ROT_TWO              
              7 STORE_FAST               2 (a) 
             10 STORE_FAST               3 (b) 

  3          13 LOAD_FAST                2 (a) 
             16 LOAD_FAST                3 (b) 
             19 BUILD_TUPLE              2 
             22 RETURN_VALUE         

That is, unpacking of literal set of sizes 2 and 3 is changed to ROT instructions. This, however, changes the semantics, as construction of set would eliminate duplicates.

The difference can be demonstrated like this:
Python 3.1
>>> foo(1,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
ValueError: need more than 1 value to unpack

Python 3.2
>>> foo(1,1)
(1, 1)

Looks like changeset ed8b0ee1c531 (svn r77543) broke it.

It looks like the steps for UNPACK_SEQUENCE should be skipped when following a BUILD_SET.  I'll post a patch tomorrow (probably a one-liner).

See attached.

New changeset 912eb87946e0 by Raymond Hettinger in branch '3.2':
Issue 11510: Fix BUILD_SET optimizer bug.
http://hg.python.org/cpython/rev/912eb87946e0

New changeset db6997fb4c99 by Raymond Hettinger in branch 'default':
Issue 11510: Fix BUILD_SET optimizer bug.
http://hg.python.org/cpython/rev/db6997fb4c99

Eugene, thanks for noticing and reporting this.

Raymond, it looks like you committed this fix separately to the 3.2 branch and the default branch, instead of committing to 3.2 and then merging to default.  With svn, this wasn't a big deal, but with mercurial it will leave the 3.2 changeset unmerged, and the next person who wants to submit something will have to merge it.  (A dummy merge, since you already committed the fix to default).