[Python-ideas] Proposal for function expressions

[Stephen J. Turnbull]

Carl Johnson writes:

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

Decorators serve the same kind of purpose that define-syntax does in
Scheme, and are similarly hygenic (which is a technical term in Scheme
that more or less means "the rope is too short to get all the way
around your neck").  They are *not* worthless to me; they allow
boilerplate to be given a name, and to be applied to transform the
behavior of a function at definition time rather than invocation time.
By giving them a syntactic implementation, it becomes possible and
encouraged to associate them with the declaration of a function,
rather than placing them at some arbitrary point later in the file.
(I can just see somebody inventing a style where all the decorators
are defined and applied at the very end of the file, for example.)

Agreed, that said, "@" doesn't evoke any association with the concept
of decoration, but that's a problem of documentation.  So I guess you
had to be there to understand it....

 > And yet, @ was approved, in spite of its worthlessness (it literally
 > adds no power to the language, just sugar)

But that is true of *all* operators.  Lisp does just fine with no
operators at all.

 > and strangeness because of the perceived benefits to readability.
 > 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.

Right.  That's your opinion, and as you've seen the majority of those
posting to this thread disagree that the examples given are more
readable.  Even more distressing, all though he hasn't posted, GvR
almost certainly would be included in them.

On the other hand, most Pythonistas agree that

@compute_some_boilerplate(variant)
def foo ():
    # 20 lines of code

is more readable than

def foo ():
    # 20 lines of code
foo = compute_some_boilerplate(foo, variant)

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

Some people feel that giving names to a cognitive chunk is an
essential part of the process of chunking.  They are made
uncomfortable, and often confused, by code which is named only by its
own source (aka "blocks").  Others don't feel that way.  The former
oppose this kind of proposal strongly, the latter support it more or
less actively.

Guido apparently is in the former camp.  But I think the deciding
factor most likely is that it is the opinion of the BDFL that the harm
done by allowing blocks to the cognition of the "please give it a
name" group is much greater than the convenience to the "I don't need
a name when I've got the code in front of me" group.