[Python-ideas] Proposal for function expressions

[Carl Johnson]

Steven D'Aprano wrote:

> The key=& seems like a mysterious Perlism -- what's the & operator doing
> in there? (Admittedly, it *might* be nice to be able to write things
> like reduce(&, alist) instead of reduce(operator.and_, alist). But
> that's another story.) "do(item):" confuses me, because it looks like
> the start of a do loop, but it isn't.

The thing about this debate that confuses me is why was the @
decorator ever approved in the first place? It's line-noise, and
worse, it's line-noise with a meaning completely different from any
other language, ever. On top of that if you do help(), you get nothing
[Ed: in Python <2.6. Good job, whoever fixed this!], and Googling is
worthless. When I first learned Python, I was very confused by
decorators--in part because I didn't know "decorator" was the term to
Google for when trying to figure out the meaning of "@"!

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. 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. 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. $ has no meaning in Python, for example. 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). But I feel like there's some
deeper reason people don't think this is a readability win. What is
it?

-- Carl