> The issue is: if we allow VAR to be a
> comma-separated list of variables now, that cuts off the extension to
> (a) in the future; so the PEP would have to be amended to state that
> VAR must be a single variable or a list of variables IN PARENTHESES.
> Thoughts?
I am not sure how relevant this is, but the syntax "x as (a, b)" sure looks
to me like (a, b) is a tuple.
Of course, I'm biased by ML, which has a feature that I wish Python had:
fun f(x as (a, b)) = ...
This says that f's argument must be a 2-element tuple. It binds x to the
argument and also binds a and b to the argument's components.
Of course the program could be written this way:
fun f(x) = let val (a, b) = x in ... end
but the "as" syntax is more succinct, direct, and convenient.
If such a feature were implemented in Python, I would imagine it to allow
usages such as
x as (a, b) = (3, 4)
which would be equivalent to
x = (a, b) = (3, 4)
Of course, this usage shows that the syntax is unnecessary in this context,
but what I care about is
def f(x as (a, b)):
# ...
which has the advantage over the alternative
def f(x):
(a, b) = x
# ...
that if you call f with the wrong arguments, you get a clearer diagnostic
message.
It's kind of an edge case, and I am not seriously pushing for its adoption,
but I do think it worth pointing out that when I see "x as (a, b)", that's
what it immediately brings to mind.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
