[Python-3000] sets in P3K?

[Steven Bethard]

On 4/28/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> {} however, can appear only standalone. It is not permitted for it to follow
> an expression. If we change that, we can use it to support an alternate
> invocation syntax for functions that currently expect an iterable as their
> first argument. "EXPR{ARGS}" would be equivalent to "EXPR((ARGS,))", with the
> following differences in the parsing of ARGS:
>     x:y would be permitted, and map to a 2-tuple (x, y)
>     x:y:z would be permitted, and map to a 3-tuple (x, y, z)
>     x=y would be permitted, and map to a 2-tuple ('x', y)
>     *x would be permitted, and would extend the passed in tuple with x
[snip]
> Explicitly constructed sets would look like:
>      set() == set{}
>      set(x)              # No braced equivalent
>      set([x]) == set{x}  # Ignoring list comprehensions
>      set((x,)) == set{x}
>      set((a, b, c)) == set{a, b, c}
>
[snip]
> Joining a known set of strings, or extend a mutable sequence also benefits:
>
>    ", ".join{x, y, z}
>    seq.extend{x, y, z}
[snip]
> The question of "accept an iterable or accept *args" goes away - the obvious
> way to do it is to accept an iterable, and then use a braced call to
> conveniently invoke the call with a literal sequence instead of a pre-existing
> iterable.

+1

This is really nice.  I know I've written ", ".join([x, y, z]) a
number of times and wished there was a nicer way to write it.  I've
also debated countless times with function APIs whether to give them a
*args or iterable argument.  For the sake of flexibility, I know I
should use a single iterable, but when I know I'm going to use the
constructor primarily with list literals, it's hard to resist the
convenience of the *args form.  I really like that this proposal gives
me one obvious way of doing things. =)


STeVe
--
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy