[Python-ideas] Enhance definition of functions

Andrew Barnert abarnert at yahoo.com
Wed Jul 31 08:47:53 CEST 2013


On Jul 30, 2013, at 23:23, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> 
> On 31 Jul, 2013, at 3:41, Terry Reedy <tjreedy at udel.edu> wrote:
> 
>> On 7/30/2013 11:59 AM, Ronald Oussoren wrote:
>> 
>>> "Never" is a long time. AFAIK the main reason why Python doesn't have
>>> multi-line lambda's is that nobody has proposed a suitable syntax yet
>>> (and not for lack of trying, the archives of this list and python-dev
>>> contain a lot of proposals that were found lacking).
>> 
>> There is also the fact that a generic .__name__ attribute of '<lambda>' is inferior to a possibly unique and meaningful name. This is not just in tracebacks. Consider
>> [<built-in function sin>, <built-in function cos>]
>> versus
>> [<function <lambda> at 0x0000000003470B70>, <function <lambda> at 0x0000000003470BF8>]
> 
> 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...).

Of course often, when I run into this, it's a matter of trying to write something that _could_ be an expression, without even needing a lambda... except that it would be a huge mess of partial and compose and other HOF calls and uses of operator functions and sometimes itertools stuff that would all be trivial in a different language but is horribly unpleasant in Python. And then I can compare the cost of having to write an out of line function in Python to the cost of writing the surrounding code in Haskell and I feel better. :)


More information about the Python-ideas mailing list