No other language does that, because it makes very little sense. This proposal will make Python behave more like every other programming language that supports anonymous functions.
Having thought about it for a couple of hours, I don't think there is any good solution for adding multi-line anonymous functions to Python. The suggested syntax feels non-Pythonic, is inherently unexpressive and difficult to read, only useful in a few select use-cases while not solving the holy grail of 'pleasant anonymous functions', and the single problem it's solving isn't common enough or big enough to need dedicated syntax and could already largely be solved with a named function. The fact it enables 'misuse' via Ruby-style iteration, going against Pythonic ideals of 'one way to do things', doesn't work in its favour either.
I don't think analogies with decorators are good either. The advantages of decorators is they transform something otherwise difficult-to-read and unexpressive into something easier-to-read and more expressive, whereas this makes something that's easy-to-read less expressive with the only advantage being terseness. Python, unlike other languages, focuses primarily on clarity over code length.
Haskell is newline-and-indentation-based and allows multi-line anonymous functions.
With that in mind, I often prefer to name functions, but not let them be globally callable, i.e.
f = (g . h) where
g = (2*)
h = (1+)
(defun f (x)
(flet ((g (x) (* 2 x))
(h (x) (1+ x)))
(g (h x))))
sub f {
my $g = sub { 2 * $_[0] };
my $h = sub { 1 + $_[0] };
return $g->($h->($_[0]));
}
The Haskell solution is very similar to how Python currently deals with this situation, similar to your Perl and Lisp examples, by allowing named local functions within a block (rather than at statement-level), and also allowing a syntax for single-line anonymous functions (via "lambda").
I did actually ponder a Haskell-like syntax for Python, but decided it's less than ideal. Allowing assignment after a statement makes things more difficult to read, especially in imperative languages.
def f(x):
def g(x): return 2 * x
def h(x): return 1 + x
return g(h(x))
function_name(
def(e):
print e
def(f):
print f
)
function_name(def(e):
print "e", def(e):
print "f"
)
Then you end up with Haskell-style:
function_blah(e, f) where:
e = lambda e: print e
f = lambda f: print f
There is the alternative
within blah def e(e):
print e
blah(e)
So Python's blocks prevent you doing nice multi-line anonymous functions.
So your only choice is to create a special-case solution, as suggested in this post. So you end up thinking:
using blah do (e):
print "e"
But I think something like Ruby's block syntax should be doable, and probably you can even pass multiple blocks, with some limitations on which parameters can receive them. Here's another shot at it, just for fun: http://codepad.org/mVigj978
Having anonymous functions only for the situation where you are passing exactly one of them to another function and it is the last argument is much more arbitrary than the current style of always temporarily binding functions to names.
I don't think either is true -- if you have more flexibility in the syntax, you'll do more with it.
@reg_callback(button.onclick)
def callback():
do_stuff()Read some Ruby code that uses blocks for an example of how passing anonymous functions can become a very clear and natural idiom. In Ruby, you can write your own simple control flow constructs in the form of functions that take a block -- in fact the idiomatic way to iterate through a collection in Ruby is with a function rather than a built-in control flow construct.
In languages like Lisp and Smalltalk, where functions can naturally take more than one in-line block, you can write any control flow construct yourself.