[Python-ideas] Enhance definition of functions

[Andrew Barnert]

From: Paul Moore <p.f.moore at gmail.com>
Sent: Wednesday, July 31, 2013 2:15 AM


>On 31 July 2013 07:47, Andrew Barnert <abarnert at yahoo.com> wrote:
>
>>> It might be lack of imagination on my part, but I have a lot of nested functions named "function" or "callback" that are too complex to be a lambda, but too simple or specialized to bother making them proper functions. The key function for sort is one of the usecases.
>>>
>>> I'd love to have anonymous functions for that, but haven't seen a proposal for those yet that would fit the language.
>>
>>Would it really help anything? If you're worried about keystrokes you can always call them "f" instead of "function". And I don't think anonymous functions would be as nice in tracebacks as even genetically-named ones.
>>
>>I think having to define them out of line is usually a more serious problem than having to name them, and if you solve that problem you may get the other one for free (although admittedly you may not, as the @in proposal shows...).

>The only real reason I ever use lambdas (and would sometimes like a multiline version or similar) is for readability, where I want to pass a callback to a function and naming it and placing it before the call over-emphasises its importance. It's hard to make this objective, but to my eyes
>
>
>    def k(obj):
>        return obj['x'] / obj['y']
>    s = list(sorted(l, key=k)
>
>
>reads marginally worse than
>
>
>    s = list(sorted(l, key=k)) where:
>        def k(obj):
>            return obj['x'] / obj['y']
>
>
>simply because the focus of the block of code (building a sorted list) is at the start in the latter.

This is "the @in proposal" I referenced earlier—specifically, PEP 403 (http://www.python.org/dev/peps/pep-0403/). With PEP 403, your code would actually look like this:

@in s = list(sorted(l, key=k))
def k(obj):
    return obj['x'] / obj['y']

Your syntax is closer to that of PEP 3150, but if you look toward the end of PEP 403, it specifically describes using PEP 3150-like syntax for the (simpler) PEP 403 semantics, and the result is exactly your suggestion except with the keyword "given" instead of "where".

>But because the difference is so subtle, it's very hard to get a syntax that improves things sufficiently to justify new syntax. And it's also not at all obvious to me that any improvement in readability that can be gained in simple example code that you can post in an email, will actually still be present in "real world" code (which, in my experience, is always far messier than constructed examples :-))

The motivating examples in PEP 403 are, like yours, marginally better, for pretty much the same reason—putting the focus of the code at the start. And when PEP 403 pops up in relation to some different proposal, it's "if we had PEP 403, there would be less reason to want this new idea… but still not zero". And so on. It feels like there should be more benefit to the idea than this, but nobody's found it yet. And that's why it's stalled and deferred. If you can come up with a better motivating example, even if it's too hard to put into an email, that could definitely be helpful.

But anyway, I think you're mostly agreeing with me. When neither lambda nor def feels right, it's usually not because you really want a multi-line expression, or a multi-line anonymous function, but because you want to get the petty details of the function "out of the way" of the important code, right?