[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
needed.
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
BUILD_SET?
Which doesn't seem like a good idea because it means that
{(x for x in iterable)} == {x for x in iterable}
Georg
More information about the Python-3000
mailing list