RetroSearch Browse

Mon Sep 19 20:11:35 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-September/056493.html

> 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 =
		let
			val (y, z) = x
		in
			(* ... *)
		end

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-September/056493.html below:

[Python-Dev] removing nested tuple function parameters