[Python-Dev] removing nested tuple function parameters

Andrew Koenig ark at acm.org
Mon Sep 19 20:11:35 CEST 2005

> I agree that we shouldn't mess with them in 2.x. Yet I think they are
> a candidate for being dropped from Py3K. While every feature is used
> by *someone* (as the feedback to Brett's query clearly shows) this one
> has several things against it. For every user who is fond of them
> there are probably ten who have never even heard of it. It's purely
> syntactic sugar (the only place where it's not trivial to replace is
> in a lambda). I've encountered quite a few people who had a hard time
> reading code that uses it. I personally prefer reading code that
> doesn't use this feature; for one thing, when this is used, you can't
> refer to a parameter by name.

I don't know whether this qualifies as an argument for or against the
feature, but ML has a nice way of referring to such a parameter by name:

	fun f(x as (y, z)) = (* ... *)

This defines f as a function with an argument that is a 2-element tuple.
The name x is bound to the argument, and the names y and z are bound to the
two components of the argument.

This example is syntactic sugar for

	fun f x = let val (y, z) = x in (* ... *) end

but it I find the sugared version easier and more natural to write and
understand.  If you don't know ML, the unsugared version might be easier to
follow if I indent it Pythonically:

	fun f x =
			val (y, z) = x
			(* ... *)

The idea is that the stuff between "in" and "end" is executed in the scope
of the bindings between "let" and "in", after which those bindings are

More information about the Python-Dev mailing list