[Python-ideas] Proposal for function expressions

[Paul Moore]

2009/7/14 Chris Perkins <chrisperkins99 at gmail.com>:
> 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.

That's a very telling statement. To me, that code is utterly baffling.
(Seriously! Without analysing it line by line, it means nothing to
me). By contrast.

def uc_name(item):
    name = item.split('-')[1]
    return name.upper()

y = sorted(x, key=uc_name)

is a lot clearer to me. And it would be even better if I knew what was
going on with the splitting of items on dashes, and taking the second
bit, was all about. Then, I could give the function a more meaningful
name.

[[An admission here - when I first wrote that example, I spelled the
function name differently in the 2 places. So my "see how much better
my way is" example was wrong - in a way yours couldn't be! In my
defence, the error would have come up as soon as I ran the code, and I
could say that if I had thought of a better name it wouldn't have
happened - but nevertheless. In the spirit of friendly debate, I'll
give you that argument for your case free of charge :-)]]

My point is that *technically* I can see what the 2-line block of code
does - but without giving it a name, I don't have a clue what it's
*for*.

But I don't imagine we're ever going to agree on this. Let it stand
that (without implying any criticism - people differ) your idea of
readable code is confusing and difficult to follow for me. Hence my
distrust of readability arguments :-)

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

Good try, but you don't win that easily :-)

I don't think this construct improves readability. Personally, I think
it *harms* readability (although I concede that like anything, it
could be used tastefully). What I was saying was that your *only*
argument was readability, and I don't think that is enough of an
argument in itself.

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

It has to improve readability, uncontroversially, in enough cases to
justify the cost in terms extra of language complexity (both for
implementation, and definition/teaching).

To demonstrate the benefits, a good place to look is often the
standard library. If your proposed change can be demonstrated to
improve the code shipped with Python in the stdlib, in a number of
places, people will start to listen.

Also, apart from the basic cost of any change (the fundamental barrier
to entry, if you like) the cost of your change is higher because there
are obscure corner cases that aren't easy to explain - witness
questions here about interaction of this form with if statements, etc.
This is a unique construct in that it's the only indentation-sensitive
multi-line element of an expression. People don't have an intuition
about how it "should" work, because there's nothing similar to
extrapolate from. Ultimately, that's why this idea (in one form or
another) has been around for so long and never been accepted - nobody
has ever managed to come up with an idea that prompted the "oh, yes,
obviously!" reaction in people needed to confirm that it's the "right"
solution.

I'd like to think that one day, someone will come up with the ideal
answer which will finally address all these "extended lambda"/"code
block" needs. But I don't think it's happened yet.

Sorry :-)
Paul.