>For more complex computation, named functions, which can be limited to the local scope to avoid any name-collision problems, are the way to go, as a 2006 blog

>For more complex computation, named functions, which can be limited to the local scope to avoid any name-collision problems, are the way to go, as a 2006 blog post from Guido van Rossum stated. In his opinion, there is no Pythonic way to embed a multi-statement construct in the middle of an expression. Well, there's no Pythonic way because Guido didn't let one be. >The problem, in a nutshell, is that Python blocks are delineated using white space, not braces or keywords like begin and end, so any expression used to create a function with multiple statements would need a way to incorporate white space—or it will not look like Python at all All kinds of other syntax made it to the language in the last 18 years, but an "end" delimiter for multi-line closures cannot? >The problem, though, as Paul Moore pointed out, is that there is a process that needs to be followed so that the core developers will reconsider a longstanding decision of this nature; someone needs to explain why the objections raised before are no longer valid Well, the objections raised before" are all subjective opinions about how this is unpythonic, so good luck refuting feelings. You're either for it, or against it, and if you're for it and use subjective opinions as objections, then the other side can't really do anything, even if they state objective facts (like how developers are by now well familiar with them, how they avoid polluting the local namespace, how they're useful to setup APIs that provide the mechanism and you pass in the policy at the call site, and so on). >But without a solution to the syntax issue, the whole argument is not worth having. Well, there can't be a solution if the problem "we don't like how it looks" - the actual practical problem can certainly be solved.