[Python-ideas] Proposal for function expressions

Paul Moore p.f.moore at gmail.com
Tue Jul 14 17:04:28 CEST 2009


2009/7/14 Chris Perkins <chrisperkins99 at gmail.com>:
> Failing that, it looks like our proposals will die the same
> not-so-slow death for lack of interest. Oh well.

OK, so I'm not accused of "lack of interest"... :-)

First of all, I have never felt the need for a construct like this. So
it adds nothing but complexity to the language for me. But assuming
that in the future, I do find a need for this, or there's a large
group of other users who would find this useful, please can you
address the following:

Your

fn() do (...):
    stmt1
    stmt2

is equivalent to

@fn
def _(...):
    stmt1
    stmt2

Why is your proposal better (ignoring "I like it better", as
subjective preferences other than Guido's don't get the language
changed)?

For the case of function calls with arguments, why is

fn(a, b, c) do(...):
    stmt1
    stmt2

better than

@functools.partial(fn, a, b, c)
def _(...):
    stmt1
    stmt2

(note that I could make my version look a bit nicer by a "from
functools import partial", so you're still not allowed to argue
aesthetics :-))?

That leaves your general cases where you stick an "&" somewhere in the
call as a placeholder. Only a couple of your motivating examples used
that form, and to be honest I didn't find them very convincing. By the
time you're getting that complex, I really do think you're trying to
cram too much into one statement (and I know that's a subjective
statement, sorry :-))

The same applies to the "x = fn(...) do (...)" cases that you include
in the example, but don't explicitly state in your specification. I
don't see any objective reason to think your form is clearer - yes,
"put the assignment, which is the main thing, up front" is an argument
in your favour, but "don't put too many things together just to avoid
thinking of a name" is an equally valid against.

OK, I hope that helps. I'm still against the idea, but I hope this
gives you some idea why - it's not simply indifference.

A construct like this needs to bring something better than mere
improved readability to the language, in my view.

Paul.



More information about the Python-ideas mailing list