[Python-ideas] YAML (yet-another-multiline-lambda)

[Antony Lee]

I don't have any experience with JS, so perhaps I don't understand the 
issues well... but if you define a callback in a method, you don't need to 
call "bind" as "self" will be captured as a closure variable anyways (in 
particular, can you explain what you mean by "this would make things 
worse"?).  Also, if you really need to bind the first variable and don't 
want to use partial, you can also use __get__, which exactly creates bound 
methods: (lambda x: x).__get__(1)() ==> 1.
Also, the syntax (in particular the extra parentheses) was specifically 
chosen to make parsing relatively easy (avoiding awkward issues of "when 
does the 'def' end?").

PS: I'm using the Google Groups interface and feel like I'm making a mess 
of the email layouts.  Any hints on whether this can be avoided -- or do I 
have to go through mailman instead?

Antony

On Tuesday, October 22, 2013 9:52:31 AM UTC-7, Andrew Barnert wrote:
>
> On Oct 22, 2013, at 3:10, Antony Lee <anton... at berkeley.edu <javascript:>> 
> wrote: 
>
> > Specifically, I suggest that the "def" (and possibly the "class") 
> keyword(s) may be used in an expression context, if immediately surrounded 
> by parentheses.  The indentation of the body of the function is given by 
> the indentation of the first line after the def. 
>
> I don't think this idea will fit well with Python's OO. 
>
> Partly this is based on JS experience, where you have to write .bind(this) 
> all over the place because your callback--or, worse, some callback later in 
> the chain--needs access to this. 
>
> In Python, f.bind(this) is spelled types.MethodType(f, self, type(self)), 
> and classes are used more than in JS rather than less. Especially since the 
> paradigm cases for callbacks--network transports, GUI events, etc.--are 
> also paradigm cases for objects--protocols, controllers, etc. At best this 
> will lead to two completely different styles for doing things that are hard 
> to tie together. At worst people will tie them together the same way they 
> usually do in JS, leading to ugly circumlocutions where people bind self to 
> other variables in closures (like the common "that = this" in JS), wrap 
> functions in extra lambdas just to turn them into methods, or use partial 
> to do the same, etc., to avoid the need to bind(this) at every step on the 
> chain. And the fact that you can often rely on capturing self directly in a 
> closure doesn't make things better, but worse, because it's not nearly 
> often enough to count on. 
>
> In fact, I'd go so far as to say that not having inline def is part of the 
> reason python server code is usually easier to read than node server code, 
> despite node having an API not that far from Python frameworks like 
> Twisted. 
>
> As a secondary concern, this would make it harder to partially parse 
> Python the way IDEs and other code managing tools often do. 
> _______________________________________________ 
> Python-ideas mailing list 
> Python... at python.org <javascript:> 
> https://mail.python.org/mailman/listinfo/python-ideas 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131022/d893d5c0/attachment-0001.html>