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

Andrew Barnert abarnert at yahoo.com
Tue Oct 22 18:52:31 CEST 2013


On Oct 22, 2013, at 3:10, Antony Lee <antony.lee at 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.


More information about the Python-ideas mailing list