[Python-ideas] Language proposal: variable assignment in functional context

[Nick Coghlan]

On 17 June 2017 at 17:03, Sven R. Kunze <srkunze at 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 at gmail.com   |   Brisbane, Australia