On 2 March 2016 at 22:46, Ethan Furman
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.
I actually find the second case more readable, because the expression comes first. Having said that, I don't particularly like the proposal, but it's not really on grounds of readability. Or, for that matter, because it looks like a generator. My problem with the proposal is mainly that trying to cram too much into one expression is nearly always a mistake in Python. The language isn't expression-based and long, over-complex expressions are hard to work with and reason about. Splitting things up into smaller named subexpressions, or using conditional statements and loops rather than conditional expressions and comprehensions, nearly always makes things more readable (unless, like me, you're really bad at naming and end up with bits called e1, e2, e3... :-)) So a "nicer syntax for lambda" isn't really that helpful - we have one already, it's called "def" :-) For background, I've been working recently with a library that focuses strongly on providing a language for building complex expressions. The functionality is really powerful, but oh, boy, it's a struggle to express my intention in a single expression. So the basic problem for me is that the proposal doesn't offer huge benefits, and it's solving a problem that people should probably try to avoid in the first place. Paul PS For the record, I dislike the lambda syntax intensely - the odd keyword, the fact that "lambda" is sometimes almost as long as than the expression I'm using, the use of the mid-line colon which is hard to spot, ... So in principle I'm inclined to support "improvement" proposals.