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 [, ] -- Terry Jan Reedy

On 7/31/2013 1:20 AM, Steven D'Aprano wrote:

On 31/07/13 11:41, Terry Reedy 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 [, ]

True, but if we're going to hypothesize nice syntax for multi-line lambdas, it's not much harder to imagine that there's also nice syntax to give them a name and a doc string at the same time :-)

But then they would not be anonymous. When I have a multiple line expression, I often pull out an anonymous expression and give it a local name to use within the expression to make the expression shorter and more comprehensible. So does most everyone else. So I have no desire to do the opposite with function definitions by sticking multiple line definition in the middle of an expression. I know Lisper do that, and the result is ofter difficult to impossible to read. In sort(key=?) calls, I use lambda for short, one-use key expressions, but I would never want to inject a multiple line expression into the middle. To me, it make the code less readable than separating a non-trivial key idea from the sort idea. -- Terry Jan Reedy

On 31 Jul, 2013, at 3:41, Terry Reedy 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 [, ]

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. Ronald

On 2013-07-31, at 08:37 , Haoyi Li wrote:

I'd like multiline lambdas too, but the syntax is a thorny problem. F# is the only language I know (are there others?) that allows you to mix whitespace-delimited and paren-delimited expressions, e.g. with whitespace-blocks inside parens:

let f n = n + ( if n % 2 = 0 then printf "lol" 1 else printf "omg" 2 )

Haskell can do that: f n = n + ( case n `mod` 2 of 0 -> unsafePerformIO $ do putStrLn "lol" return 1 1 -> unsafePerformIO $ do putStrLn "omfg" return 2 ) although a difference is that it doesn't have statement blocks, only expressions (`do` blocks are sugar for monadic chain expressions)

On 31 July 2013 07:47, Andrew Barnert 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. 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 :-)) Paul

On 1 August 2013 09:17, Andrew Barnert wrote:

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?

Yeah, I've been grappling with this problem for years, which is why I have two competing deferred PEPs about it :) For certain kinds of problem, the natural way to think about them is as "I want to do X", and as an incidental part of doing X, you need to define a function that does Y. Sorting, complex comprehensions, various flavours of event driven programming (especially GUI programming, where the yield-driven approach of PEP 3156 may not be appropriate, as well as the low level transport code for PEP 3156 style systems). Lambda isn't a great solution because it embeds all the complexity of the function directly in the main expression, obscuring the fact that the overall operation is "do X". Ruby's block syntax is an elegant solution, but the specific problem with adapting that to Python is deciding how to spell the forward reference to the trailing definition. Ruby solves that problem through a convention (the block is just the last positional argument), but Python has no such convention - there's a wide variety of signatures for higher order operations, and a syntax that required new signatures for everything is no solution at all. PEP 403 is the approach I dislike least so far, but that's a far cry from being something I'm willing to propose for inclusion in the language. The "@in" does hint at the out of order execution nicely, but it's also a bit too heavy (drawing attention away from the subsequent simple statement), and as an ordinary name, the forward reference doesn't quite stand out enough. PEP 3150 could possibly by improved by having the hidden function implicitly end with (a more efficient equivalent of) "return types.SimpleNamespace(**locals())" and introducing "?" as a forward reference to that result: sorted_data = sorted(data, key=?.k) given: def k(item): return item.attr1, item.attr2 But it's hardly what one could call a *concise* syntax. On the other hand, it *does* let you do some pretty neat things, like: dispatch_table = vars(?) given: def command1(*args, **kwds): ... def command2(*args, **kwds): ... def command3(*args, **kwds): ... I would also tweak the early binding syntax to require an additional keyword to make it read more like English: seq = [] for i in range(10): seq.append(?.f) given i=i in: def f(): return i assert [f() for f in seq] == list(range(10)) Using up another precious symbol would be a big call, but it's starting to feel more like something of sufficient power to justify new syntax. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 2 August 2013 23:55, Antoine Pitrou wrote:

Le Fri, 2 Aug 2013 22:48:33 +1000, Nick Coghlan a écrit :

...

I would also tweak the early binding syntax to require an additional keyword to make it read more like English:

seq = [] for i in range(10): seq.append(?.f) given i=i in: def f(): return i assert [f() for f in seq] == list(range(10))

I think any "inline function" proposal should focus on callback-based programming for its use cases.

I think callback based programming is a *good* use case, certainly, but not the only one.

In this context, you usually have one or two callbacks (two in Twisted-style programming: one for success, one for failure), passed positionally to a consuming function:

loop.create_connection((host, port), @cb, @eb) where: def cb(sock): # Do something with socket def eb(exc): logging.exception( "Failed connecting to %s:%s", host, port)

We can't use 'where' because we know it conflicts with the SQL sense of the term in too many APIs. We're reasonably sure we can get away with "given" without too much conflict, though. Using "@" as the marker character is also problematic, since the following degenerate case will probably confuse the parser (due to it looking too much like a decorator clause): @something() given: ... I liked the notion of "?" as suggesting doubt and uncertainty - an element of "leave this undefined for now, we'll fill it in later". While the out of order execution is related to decorators (hence @in for PEP 403), I think PEP 3150 is more of a different notion, especially with the revisions I suggested in this thread. I believe your example still looks reasonable with the "?." notation for the forward reference: loop.create_connection((host, port), ?.cb, ?.eb) given: def cb(sock): # Do something with socket def eb(exc): logging.exception( "Failed connecting to %s:%s", host, port) Anyway, not something that's going to happen for 3.4, but a problem I'm happy to keep chipping away at - some day we might find a proposed solution that doesn't send Guido screaming in the other direction :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Aug 2, 2013, at 9:00, Antoine Pitrou wrote:

...

Using "@" as the marker character is also problematic, since the following degenerate case will probably confuse the parser (due to it looking too much like a decorator clause):

@something() given: ...

No, that would simply be forbidden. In this proposal, "@" can only mark names of parameters in function calls. We already reuse "*" and "**" for a specific meaning in front of function call parameters, so there's a precedent for such polysemy.

That's fine if callbacks are the _only_ case you want to handle, but as Nick just explained, there are many other cases that are also useful. The middle of an if expression in a comprehension, for example, isn't a function parameter. Also, when you have a long function call expression--as you almost always do in, say, PyObjC or PyWin32 GUIs--you often want to put each parameter on its own line. While that won't confuse the parser, it could easily confuse a human, who will see "@callback," on a line by itself and think "decorator". It's probably worth taking some real examples from a bunch of different domains where you've defined something out-of-line but would use this proposal if you could, and rewriting them with each variation to see what they look like.

On 3 August 2013 02:41, Michael Walter wrote:

On Fri, Aug 2, 2013 at 6:25 PM, Andrew Barnert wrote:

...

On Aug 2, 2013, at 9:00, Antoine Pitrou wrote:

...

...

Using "@" as the marker character is also problematic, since the following degenerate case will probably confuse the parser (due to it looking too much like a decorator clause):

@something() given: ...

No, that would simply be forbidden. In this proposal, "@" can only mark names of parameters in function calls. We already reuse "*" and "**" for a specific meaning in front of function call parameters, so there's a precedent for such polysemy.

That's fine if callbacks are the _only_ case you want to handle, but as Nick just explained, there are many other cases that are also useful. The middle of an if expression in a comprehension, for example, isn't a function parameter.

Also, when you have a long function call expression--as you almost always do in, say, PyObjC or PyWin32 GUIs--you often want to put each parameter on its own line. While that won't confuse the parser, it could easily confuse a human, who will see "@callback," on a line by itself and think "decorator".

It's probably worth taking some real examples from a bunch of different domains where you've defined something out-of-line but would use this proposal if you could, and rewriting them with each variation to see what they look like.

Is the reason to mark up the variables that are defined in the with/where/given block only a technical one (to support the parser)?

It's more than just the parser that needs that extra help to make it implementable :) However, the syntactic marker is helpful for human readers, too - it makes it clear which names come from the statement local namespace, and which are just ordinary name references. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

PEP 3150 is actually pretty simple to implement using macros:

...

...

@in(map(_, [1, 2, 3])) ... def thing(x): ... return x + 1 ... thing [2, 3, 4]

The macro is about 5 lines long, since it's exactly the same as my 15-line quick lambda macro (i.e. f[_ + _] -> lambda a, b: a + b); this should have worked out of the box, requiring no additional code: @f[map(_, [1, 2, 3]] def thing(x): return x + 1 But it doesn't due to the parser not liking [] in decorators; boo for arbitrary syntactic restrictions =( =( =(. This only works for higher-order-functions with a single callback. As things stand now, the status-quo solution for multi-callback functions is to make a class and inherit from it, and fill in the methods you need to fill in. There wasn't any PEP for this but that's what people are doing all over the place: many many classes exist purely to let people fill in the missing functions. Not because the class objects have any state, or you ever intend to create objects which will live for more than one function call: class MyClass(BaseRequestClass): def print_data(d): print d def print_error(failure): sys.sys.stderr.write(str(failure)) result = MyClass().make_request() # never gonna use MyClass() ever again! Java uses this pattern too, and I do not like it. One possibility, though, would just codify/streamline the status quo, via macros: @in(make_request(_, _)) class result: def print_data(d): print d def print_error(failure): sys.sys.stderr.write(str(failure)) Which would desugar (using macro-magic and metaclasses) into def print_data(d): print d def print_error(failure): sys.sys.stderr.write(str(failure)) result = make_request(print_data, print_error) Potential bikesheds are over whether to use `_` to leave holes, or `print_data` and `print_error` as named arguments, as well as whether `result` should be a class or function def. Overall, though, it looks exactly like PEP3150 except this public_name = ?.MeaningfulClassName(*params) given: class MeaningfulClassName(): ... becomes this: @in(_.MeaningfulClassName(*params)) class public_name: class MeaningfulClassName(): ... Which is pretty close. I can put up the implementations of all of these things if anyone's interested in playing around with the syntax/semantics in the REPL. -Haoyi On Sat, Aug 3, 2013 at 1:46 AM, Antoine Pitrou wrote:

On Fri, 2 Aug 2013 09:25:05 -0700 Andrew Barnert wrote:

...

On Aug 2, 2013, at 9:00, Antoine Pitrou wrote:

...

...

Using "@" as the marker character is also problematic, since the following degenerate case will probably confuse the parser (due to it looking too much like a decorator clause):

@something() given: ...

No, that would simply be forbidden. In this proposal, "@" can only mark names of parameters in function calls. We already reuse "*" and "**" for a specific meaning in front of function call parameters, so there's a precedent for such polysemy.

That's fine if callbacks are the _only_ case you want to handle, but as Nick just explained, there are many other cases that are also useful. The middle of an if expression in a comprehension, for example, isn't a function parameter.

There may be many other cases, but almost any time people complain about the lack of inline functions, it's in situations where they are declaring callbacks (i.e. GUI- or network-programming). So, yes, I don't think the other use cases should be a primary point of concern.

...

Also, when you have a long function call expression--as you almost always do in, say, PyObjC or PyWin32 GUIs--you often want to put each parameter on its own line. While that won't confuse the parser, it could easily confuse a human, who will see "@callback," on a line by itself and think "decorator".

Even if indented, inside a parenthesis and not preceding a similarly indented "def"?

Regards

Antoine.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

It does feel like Perl, but, what if there was a keyword after the symbol? It'd be more readable and not Perl-ish, but, it wouldn't confuse the parser(or at least I wouldn't think it would). Antoine Pitrou wrote:

Le Sat, 3 Aug 2013 01:46:37 +1000, Nick Coghlan a écrit :

...

...

In this context, you usually have one or two callbacks (two in Twisted-style programming: one for success, one for failure), passed positionally to a consuming function:

loop.create_connection((host, port), @cb, @eb) where: def cb(sock): # Do something with socket def eb(exc): logging.exception( "Failed connecting to %s:%s", host, port)

We can't use 'where' because we know it conflicts with the SQL sense of the term in too many APIs. We're reasonably sure we can get away with "given" without too much conflict, though.

How about reusing "with"? There's no ambiguity with context managers since the syntactic context is different.

...

Using "@" as the marker character is also problematic, since the following degenerate case will probably confuse the parser (due to it looking too much like a decorator clause):

@something() given: ...

No, that would simply be forbidden. In this proposal, "@" can only mark names of parameters in function calls. We already reuse "*" and "**" for a specific meaning in front of function call parameters, so there's a precedent for such polysemy.

...

I liked the notion of "?" as suggesting doubt and uncertainty - an element of "leave this undefined for now, we'll fill it in later".

I don't really like it :-) "?" has other meanings traditionally: as part of the ternary operator in C-like languages (many of them), as a wildcard character in pattern matching languages, as a marker of optional matchers in regular expressions.

Also, I really don't like the idea that "?" represents a full-blown object with attribute access capabilities and whatnot. It smells too much like Perl-style (Ruby-style?) magic variables. My proposal is more limited: it's a syntactic addition, but it doesn't create new runtime objects or types.

Regards

Antoine.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

On 31 Jul 2013 04:48, "Ronald Oussoren" wrote:

On 30 Jul, 2013, at 20:30, Ryan wrote:

...

How about something like:

f = indef(x, y): print x, y

How is that different from a lambda?

And, since assignments are statements, different from def? Cheers, Nick.

Ronald

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Jul 30, 2013, at 11:30, Ryan wrote:

How about something like:

f = indef(x, y): print x, y

It's essentially storing lambdas.

You can already store lambdas. Or, more precisely, you can store functions. A lambda isn't a type; it's just a different way of creating functions, exactly the same type of functions you get from the def statement. And functions are first class values that can be bound to a name just like any other value. Meanwhile, the only advantages of lambda over def are that you don't have to come up with a name, and you can use it in an expression. So, trying to come up with a statement for giving lambdas names implies that there's something fundamental you're missing that would make your life a lot easier. Maybe you didn't know you could use def locally? Or you're trying to build code out of eval-ing strings because you don't know about closures? Or... Well, there are lots of possibilities. If you explain what you want to do that you think your new syntax would help with, I'm 99% sure Python already has a better way to do it.

On 01/08/13 13:24, Göktuğ Kayaalp wrote:

BTW, if a multi-statement anonymous function syntax was to be considered seriously, I'd recommend a lambda statement with colon replaced with a brace-delimited block

You can get an idea of how brace-delimited blocks are treated by using a __future__ directive. At the interactive interpreter: from __future__ import braces and then take it from there. -- Steven