[Python-ideas] Proposal for function expressions

[Chris Perkins]

On Tue, Jul 14, 2009 at 11:04 AM, Paul Moore<p.f.moore at gmail.com> wrote:
> 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)?

I agree that decorators can handle some of the use cases - I
anticipated that argument, and it is indeed a valid one. Nevertheless,
I think that's a bit a perversion of the the purpose of decorators.
And as you point out below, decorators are significantly more limited
in what they can do.  And besides that, "I like it better" :)

> 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 :-))?

Yes, again, that does work, but it's getting uglier (yes, I know,
subjectiveness again), and it forces the callable to be the last
argument, which is limiting.

> 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 :-))

Indeed, like any language construct it could be used for evil. I
prefer to think of it as enabling the programmer to write clearer code
in some cases - trying to prevent him from writing unclear code is, in
my opinion, a lost cause.  Some programmers will find a way to write
unclear code no matter what tools you give them.

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

For me, avoiding thinking of a name was never the primary motivation -
putting things in the "right order" is. But I do believe that there
are situations where the context that a block of code sits in tells
far more about its purpose that a name ever could - in those
circumstances, a forced function name can be useless at best, and
distracting clutter at worst. For example:

y = sorted(x, key=&) do(item):
    name = item.split('-')[1]
    return name.upper()

I think that forcing that two-line block of code to have a name would
serve no purpose - it's abundantly clear what it does. I also think
that the current state of affairs encourages poorer readability - I
mean, admit it, today you would probably write that snippet like this:

y = sorted(x, key=lambda item: item.split('-')[0].upper())

which to me loses clarity both by being crammed into one line, and by
not being able to create the local variable "name", which tells you
quite a bit about why the the item is being chopped up the way it is.

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

It does help - thank you for your comments, Paul.

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

Aha! You said "improved readability"! So I'm going to conveniently
forget everything else you said and write your name in the "pro"
column. :)

Seriously, I guess this is where we differ - I think that improved
readability _is_ a sufficient goal unto itself.  The only question is
whether other people (OK, one other person in particular) thinks it
improves readability, and if so, then by how much.


Chris Perkins