2013/10/24 Stephen J. Turnbull <stephen@xemacs.org>
Antony Lee writes:
as I mentioned earlier I don't really see the need
It's not a *need*, it's a *style*. Ie, it's just the way Pythonistas do things.
Many fledgling Pythonistas, especially those who come from other languages, hanker after anonymous functions or Ruby blocks (a somewhat different concept AFAICT), and some experienced Pythonistas sympathize with them. But there's no real reason why some functions shouldn't have a name, and Guido (the ultimate authority on "Pythonic") isn't a fan of lambda, so (unless a pressing need or a really good syntax appears) there seems to be little chance of the existing feature (expressions as lambdas) being extended.
I think you've misunderstood the aim of my proposal. While my proposal does contain the possibility, as a syntax extension, to define anonymous lambdas (or functions, if you prefer), in the middle of an expression (as opposed to "in a statement"), the core idea is about *named* lambdas (or functions, etc.). From the very beginning I said that allowing the anonymous form ("(def (...): ...)" instead of "(def name(...): ...)") was not a critical part of the proposal.
for binding lambdas to objects in the first place.
I think you've misspoken here. Lambdas *are* objects, and that's why names can be bound to them (and then they're called "functions").
I was specifically referring to Andrew Barnaert's reply, which I quote here: Partly this is based on JS experience, where you have to write .bind(this)
all over the place because your callback--or, worse, some callback later in the chain--needs access to this.
Specifically, I was asking his to clarify the relevance of such an issue as a locally defined lambda (etc.) already captures "self" without the need for a call to a JS-like bind (which is effectively spelled __get__ in Python).
What people complain about is the fact that the normal way to create a lambda (callable function object or something like that) is "def", which also binds a name to the object. They think that is wasteful or something.
No, that is not what I complain about. Just look at the other currently active thread on context manager semantics, where Nick Coghlan said it *also* means that we *don't* currently have a clean syntax for single
use callbacks.
Hence the time I've put into PEP 403 and 3150 over the years - a key objective for both of them is providing a cleaner solution for the problem of single use callbacks (including those that modify local variables of the containing function).
Another example is when you want to provide a dictionary of callbacks (e.g. to be triggered by various command line options), say at global scope, without putting the callbacks themselves in that scope). See Serhiy Storchaka's suggestion on why multiline lambdas are not essential here:
callbacks = {
"foo": (def foo(): <...>), # note how the parentheses disambiguate where the last comma belongs "bar": (def bar(): <...>) }
def class_to_map(cls): return {n: f for n, f in cls.__dict__items() if n[0] != '_'}
@class_to_map class callbacks: @staticmethod def foo(): ... @staticmethod def bar(): ...
I don't think abusing the class statement is particularly elegant either (and good luck if you want to preserve order... what, I have to provide a metaclass that overrides __prepare__ for doing this?), and moreover this solution doesn't even work as it is written (it needs a small fix... quick, can you spot it)?
Steve
Antony