Mike Meyer wrote:
On Tue, 20 Oct 2009 13:34:11 +0200 Masklinn <masklinn@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@gmail.com | Brisbane, Australia ---------------------------------------------------------------