
On 17 June 2017 at 17:03, Sven R. Kunze <srkunze@mail.de> wrote:
If so, I don't know if it just complicates the language with a feature which does not save writing nor reading nor cpu cycles nor memory and which adds a functionality which is already there (but in reverse order).
Maybe there are more benefits I don't see right now.
You've pretty much hit on why that PEP's been deferred for ~5 years or so - I'm waiting to see use cases where we can genuinely say "this would be so much easier and more readable if we had a given construct!" :) One of the original motivations was that it may potentially make writing callback based code easier. Then asyncio (and variants like curio and trio) came along and asked the question: what if we built on the concepts explored by Twisted's inlineDeferred's, and instead made it easier to write asynchronous code without explicitly constructing callback chains? I do still think the idea has potential (and Steven's post does a good job of summarising why), since mathematical discussion includes the "statement (given these assumptions: form)" for a reason, and pragmatically such a clause offers an interim "single-use namespace" refactoring step between "inline mess of spaghetti code" and "out of order execution using a named function". However, in my own work, having to come up with a sensible name for the encapsulated operation generally comes with a readability benefit as well, so... Cheers, Nick. P.S. One potentially interesting area of application might be in SymPy, as it may make it possible to write symbolic mathematical expressions that track almost identically with their conventionally written counterparts. That's not as compelling a use case as PEP 465's matrix multiplication, but it's also not hard to be more compelling than the limited set of examples I had previously collected :) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia