[Python-3000] Set literals

Georg Brandl g.brandl at gmx.net
Mon Aug 28 21:52:53 CEST 2006

Guido van Rossum wrote:

>> > Georg, can you do something about repr() of an empty set? This
>> > currently produces "{}" while it should produce "set()".
>> Right, forgot about that case. I'll correct that now.
>> (Grr, I even mindlessly changed the unittest that would have caught it)
> Checkin?

Done. It now also renders repr(frozenset()) as "frozenset()", which should
cause no problems though.

>> In the meantime, I played around with the peepholer and tried to copy
>> the "for x in tuple_or_list" optimization for sets. Results are in SF
>> patch #1548082.
>> >> Set comprehensions are not implemented.
>> >
>> > ETA?
>> There are some points I'd like to have clarified first:
>> * would it be wise to have some general listcomp <-> genexp
>>    cleanup first? This starts with the grammar, which currently is slightly
>>    different (see Grammar:79), and it looks like there's quite a lot of
>>    (almost) duplicated code in ast.c and compile.c too.
> I expec this cleanup to be quite a bit of work since the semantics are
> seriously different. ([...] uses the surrounding scope for the loop
> control variables.)

I didn't say that I wanted to champion that cleanup ;)

> However you might be able to just cleanup the grammar so they are
> identical, that would be simpler I suspect.

Looking at the grammar, there's only testlist_safe left to kill, in
favor of or_test like in generator expressions. The old_ rules are still

Hm. Is the precedence in

x = lambda: 1 if 0 else 2

really obvious?

>> * list comprehensions are special-cased because of the LIST_APPEND opcode.
>>    If there isn't going to be a special-cased SET_ADD, it's probably the
>>    easiest thing to transform {x for x in a} into set(x for x in a) in the
>>    AST step, with "set" of course always being the builtin set.
> Right. That might actually become a prototype for how to the list
> translation as well.

Would this need a new opcode, or should generators be special-cased by

Which doesn't seem like a good idea because it means that
     {(x for x in iterable)} == {x for x in iterable}


More information about the Python-3000 mailing list