[Python-ideas] Proposal for function expressions

[Jim Jewett]

On 7/14/09, Carl Johnson <cmjohnson.mailinglist at gmail.com> wrote:
> Steven D'Aprano wrote:

> The thing about this debate that confuses me is why was the @
> decorator ever approved in the first place?

It wasn't, for quite a while.  I believe it was proposed for 2.2.  I'm
sure it was proposed for 2.3.  Applying it to classes as well as
functions was in the working patch -- but waited until another version
just in case.

> And yet, @ was approved, in spite of its worthlessness (it literally
> adds no power to the language, just sugar) and strangeness because of
> the perceived benefits to readability.

I have a bit of an unusual perspective; I ended up writing some drafts
of the PEP, but not because I wanted decorators.  Rather, I wanted to
avoid a really bad syntax.  (@ wasn't my favorite, but it is way
better than several of the earlier proposals -- particularly in terms
of what it doesn't assume about the future.)

Almost any syntax is a big improvement *for*the*relevant*use*cases*.
The concern is what it would do to python in general, and which future
alternatives it would cut off.

> And in my opinion, there are
> similar cases here, where readability is improved by having the
> definition of a function come after the expression to which the
> function will be passed.

Some of the examples looked like the order was an improvement.

But are there huge areas where this is needed all over the place?
(Extension frameworks such as Cocoa were mentioned for decorators.)

Is it useful across several types of programming?  (I see it as
obvious for callbacks, but maybe not so clearcut elsewhere.)

What is the cost of not doing it?  With decorators, that cost was
often delaying the wrapper for 20-30 lines, and then having to repeat
the function name three times, and then using a code style that does
confuse some people.

In this case, I think the cost of not doing it is more like "Think up
a name for the 2-3 line function, and then move the definition up
ahead of the usage."  Moving the definition is annoying, but not so
horrible with small functions, and there is no need to repeat names.
(I suppose you could argue that there is one repetition, if the
function will never be used elsewhere.)

What would the proposed syntax cost?  In the case of @, that cost was
reduced to burning a punctuation character, and explaining that
functions can be annotated -- and the annotation is more than a
comment.

For the currently proposed syntax, it confuses several issues with
suites (blocks).  It sounds like the parser can probably handle it,
but it isn't as clear that humans can.  It might well preclude later
block extensions, including more powerful versions, such as thunks or
macros.  (And it still burns a punctuation character anyhow.)

> Yet, there's a lot of resistance to this, and
> I'm not entirely sure why. If it's just a problem with using "&" and
> "do" other line-noise and keywords can be proposed to substitute for
> it.

Yes.  Or "using:", of course.  The catch is that those are all so
generic that this is only one of a zillion possible meanings -- and
for most people, not the most obvious.  A more specific keyword might
have a better chance.  (Not a *good* chance -- there is quite a high
bar for keywords -- but still *better*.)

> $ has no meaning in Python, for example.

I think it starts to with string templates.
(And I think "!" is used by some popular extensions, such as scipy,
and I think @ interfered with the leo editor, and ...)

I'm not saying it is ambiguous to the parser, but the universe of
unused ascii-punctuation isn't really all that huge.

> If it's the lack of
> function names and docstrings, there's no reason these
> lambda-like-thingies can't have support for names and docstrings added
> (as in my old proposal, for example).

That wouldn't help unless people actually used the names and
docstrings -- which again brings up the question about why existing
use of functions as first class objects isn't enough.

> But I feel like there's some
> deeper reason people don't think this is a readability win. What is
> it?

Cost-benefit.  It is harder to see the costs, because they're spread
out thinly all over the language, while the benefits are concentrated.
 But those costs are important.

In this case, it looks like the benefits are smaller than for
decorators, and the costs (at least with the proposed syntax) are
higher.  And decorators were not a shoe-in.

-jJ