On 4/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, I'm now -0 on having a set literal at all, and it's because I believe
> we can solve this problem in a more general fashion that applies to more
> functions than just the set() constructor.
>
> Currently, [] and () can appear both standalone or following an expression
> (list literals and comprehensions, and subscripting for [], tuple literals and
> precedence manipulation, and function calls for ())
>
> {} 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
+1. This looks like a really nice option.
One downside, which I only point out because someone will, is that
optimization opportunities will be lost for the usual reason - the
optimizer can't be sure that set (or whatever) hasn't been reassigned.
But I still see that as something to be addressed independently, if at
all.
Paul.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
