[Python-ideas] Proposal for function expressions

[Chris Perkins]

On Tue, Jul 14, 2009 at 7:41 AM, Carl
Johnson<cmjohnson.mailinglist at gmail.com> wrote:
> This idea seems to be almost identical to my thread from November,
> "Proposal for Ruby-style anonymous block functions      (that don't kill
> the indention)":
> http://mail.python.org/pipermail/python-ideas/2008-November/002340.html

Cool! I had not seen that thread, but the fact that you and I have
proposed nearly the same thing independently increases the odds that
I'm not just nuts. :)

> The real difference is that your proposal uses & (which is a bad idea,
> since & already has a meaning: __and__) and in
>
> foo() do:
>   BODY
>
> it implicitly injects the BODY function into the args of foo, which
> violates Explicit Is Better Than Implicit.

I considered the use of a "magic" placeholder character to be an
unfortunate but necessary evil - the alternative seemed to be to
restrict the block/def-expression to becoming the last argument to the
function call that it follows, and that was just too restrictive. I
have no particular attachment to "&" - but note that there is no
ambiguity with the bitwise and operator, as far as I can tell. Eg.
this works:

>>> def f(a): return a()
...
>>> 3 & f(&) do: return 5
1

(not that you would write real code like that...)

> I agree though that sometimes rather than doing
>
> def spam():
>   BODY
> result = foo(spam)
>
> you would rather do
>
> result = foo(spam*) *To Be Defined on the next line, OK!
> def spam():
>   BODY
>
> because it reads better. As I understand it, this was the reason the
> decorator syntax was invented. Basically,
>
> @classmethod
> def foo():
>    BODY
>
> reads better than
>
> def foo():
>    BODY
> foo = classmethod(foo)
>
> so decorators are just syntatic sugar to improve readability.
>
> So, I agree with the basic motivation of your proposal, but I think
> the specifics of it aren't as good as my old one (although, I *would*
> think that, wouldn't I?) and from experience, I expect the BDFL to
> come and give you -2 in a couple days if the thread keeps up…
>
> In terms of refining my old proposal, it strikes me that ! isn't used
> in Python currently. If we have to use a sigil of some sort, we could
> try:
>
> new_list = sorted(old_list, key=!keyfunc)
> def keyfunc(item):
>    normalize data…
>
> or something to that effect with the general semantic being that !
> means "here comes a variable name, I will define this variable on the
> next line, please wait for it!"

I prefer not repeating the function name, I prefer putting the "do:"
(or "def:") on the same line (makes it clearer that the indented block
is effectively part of the expression that it follows), and I like the
fact that the function has no name - it tells you immediately that
"this function is only used within this one call - don't go looking
for uses of it later on, because they won't be there".

Other than that, it seems we are in perfect agreement on the feature.

It also seems that your earlier proposal met with the same rabid
ambivalence that mine has so far :)

A couple of interesting quotes from the discussion of your proposal:

Carl: "this proposal is not about adding power to Python, just making
things more readable"
Exactly!

Greg: "You could just allow any expression-statement to be followed by
a block, and sort out whether it makes sense later on."
That's exactly how I ended up implementing it.

Carl, if you still have any interest in this feature, you should try
out the patch - I think you'll be the first. :)  Also I'll be happy to
give you commit privileges to the hg repo where I did the
implementation, in case you want to try to come up with some middle
ground between my proposal and yours:
http://bitbucket.org/grammati/python-trunk/

Failing that, it looks like our proposals will die the same
not-so-slow death for lack of interest. Oh well.


Chris Perkins