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...@berkeley.edu> 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...@python.org
https://mail.python.org/mailman/listinfo/python-ideas