[Python-Dev] PEP 343 - next steps

[Andrew Koenig]

> 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.