[Python-ideas] a new lambda syntax

[Nick Coghlan]

Mike Meyer wrote:
> On Tue, 20 Oct 2009 13:34:11 +0200
> Masklinn <masklinn at masklinn.net> wrote:
>> The biggest (by far) advantages I see to good anonymous functions  
>> (note: Ruby's aren't, as far as I'm concerned, because due to their  
>> nature they don't easily scale from 1/call to 2+/call) are in  
>> flexibility, freedom of experimentation and possibility to keep the  
>> core language itself small: had Python had "full-blown" anonymous  
>> functions, it wouldn't have been necessary to add the `with` statement  
>> to the language. It could just as well have been implemented through a  
>> protocol or the stdlib, and people would have been free to toy with it  
>> in their projects long before it was added to the core language.
> 
> Note that this is a two edged sword, in that all those people "toying"
> with "with"-like constructs might also be publishing code using them,
> meaning that instead of having one clean construct from the core
> developers, we'd have to deal with an unknown number of variant idioms
> from most anybody.
> 
> A small core language doesn't help a lot when you have to know four or
> five different ways to build some basic construct because it's not in
> the core language.

Yup, this is certainly one of the concerns with making it too easy for
developers to invent their own syntax (and also why Guido has flatly
ruled out a macro system for Python).

The bar for anonymous blocks is a high one, because:

1. Once an anonymous block syntax is accepted into the language we're
pretty much stuck with it

2. While it does exist, the use case gap between anonymous functional
expressions (i.e. the current lambda) and full named functions is pretty
narrow (especially since the introduction of true conditional
expressions on the lambda side).

3. Code is written once and read often. Anonymous blocks run a high risk
of getting this back to front by making code easier to write but harder
to read.

The main point in favour of anonymous blocks of some kind is that having
to define the subfunction before using it often *will* get the order of
the code as written out of whack with respect to the order that makes
the most logical sense. Both decorators and the with statement involved
large elements of "don't leave important information trailing at the end
where a reader may easily miss it" so it is an argument with some merit.

Since it is a valid point that this can happen with arbitrary complex
data objects rather than solely with named functions, one past proposal
(PEP 359, the 'make' statement) involved attaching a suite to a function
call, then providing the contents of that suite as a dictionary argument
to the function being invoked. (Using the namespace to provide keyword
arguments instead would allow a new construct to be used with existing
functions, but would significantly constrain the use of temporary
variables that weren't intended for use a arguments to the function
(then again, that already happens with normal class definitions, and the
del statement seems to handle that just fine).

I should note that Guido ended up killing that PEP because he didn't
like it, but I still believe some kind of "do this, but only after
running this other suite first" out of order execution construct is more
likely to gain acceptance than trying to come up with a full anonymous
block syntax.

However, nobody has suggested a particular nice syntax for that idea
either, so, again it is unlikely to go anywhere anytime soon.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------