[Python-ideas] Thoughts on lambda expressions

[Ed Minnix]

Hi, I would just like to add a side note on this:

The library fn.py implements a class called _Callable, which gives a shorter notation for lambdas, using an underscore ( _ ), instead of declaring parameters (for example, map(_ + 1, range(10)) is the same as map(lambda n: n + 1, range(10)) ). In addition to the regular arithmetic operators, it supports the __getattr__ method. (for instance _.y is the same as lambda a: a.y)

Therefore, you do not override the general syntax of Python (other than the fact that you cannot use the code

for i, _ in some_iterable:		 # don’t use, at the end of the loop, fn._ has disappeared from the scope of the module
	do_something(i)

)

Personally, I would propose the adoption of the _ in some standard library module (e.g., functools) rather than overriding the “from” syntax if the simplification of lambdas in a goal. (Personal I find the _ much more user-friendly)

- Ed M

> On Mar 2, 2016, at 5:46 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> On 03/02/2016 12:01 PM, Abe Dillon wrote:
> 
>> More generally, I think a superior syntax for lambda would be:
>> 
>> (<expression> from <signature>)
>> 
>> The reasons I believe that's a superior syntax are:
>> 
>> a) In the vast majority of use cases for lambda expressions the call
>> signature can be easily inferred (like in a key function), so moving it
>> after the expression tends to be more readable.
> 
> And what does it look like when you have more than one paramater in the signature and/or something beside simple attribute lookup?
> 
>  'open': lambda s, cr, uid, rec, ctx: rec['state'] == 'draft',
> 
> would instead be:
> 
>  'open': rec['state'] == 'draft' from (s, cr, uid, rec, ctx),
> 
> Ouch.  That just went from bad to horrid.
> 
>> b) It doesn't use the esoteric name, 'lambda' which causes its own
>> readability issues.
> 
> On the contrary:  'lambda' lets you know immediately what you're dealing with.  The syntax you are suggesting looks like:
> 
> - a (wrong) generator
> - taking ... items? ... from some kind of container
> 
> To be fair, it looked like an interesting syntax at first glance, but deeper investigation shows serious drawbacks.
> 
> --
> ~Ethan~
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/