On 29 June 2014 07:33, Andrew Barnert firstname.lastname@example.org wrote:
Meanwhile, I think Nick's PEP 403, or something like it, is both more general and more Pythonic. Instead of trying to find a better way to embed function definitions into expressions, find a way to lift any subexpression out of an expression and define it (normally) after the current statement, and you solve the current problem for free, and a bunch of other problems too. (Although, unfortunately, none that really seem to demand solutions in practical code.)
On that last point, one of my goals at SciPy next month will be to encourage folks in the scientific community that are keen to see something resembling block support in Python to go hunting for compelling *use cases*. The fatal barrier to proposals like PEP 403 and 3150 has long been that there are other options already available, so the substantial additional complexity they introduce isn't adequately justified. The two main stumbling blocks:
- generators-as-coroutines already offer a way of suspending execution of a sequential operation, as embodied in asyncio.coroutine and contexlib.contextmanager - nested definitions of named functions are usually a readable alternative in the cases lambdas can't handle
The reason I occasionally spend time on PEPs 403 and 3150 is because I think we're missing a case where "one shot" functions could be handled more gracefully - situations where we're defining a function solely because we want to pass it to other code as an object at runtime, not because we need to reference it at multiple places in the *source* code. That's a pretty narrow niche, though - if you *do* need to invoke the same code in multiple places, than a named function is always going to be better, even if dedicated one-shot function support is available.