Syntax for one-line "nonymous" functions in "declaration style"
> On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov <alexey.muranov at
> > I only see a superficial analogy with `super()`, but perhaps it is
> > because you did not give much details of you suggestion.
> No, it's because the analogy was not meant to be anything more than
> superficial. Both are constructs of syntactic magic that aid
> readability at
> a high level but potentially obscure the details of execution (in
> relatively unimportant ways) when examined at a low level.
Since i understand that the "super() magic" is just evaluation in a
predefined environment, it does not look so very magic. I do not know
if Python can already manipulate blocks of code and environments as
first-class objects, but in any case this does not look to be too far
from the its normal behaviour/semantics.
Moreover, without this "magic", `super()` would have just produced an
error. So this magic did not change behaviour of something that worked
before, it made "magically" work something that did not work before
(but i am still not excited about it).
On the contrary, i have no idea of how in the current semantics
executing an assignment can mutate the assigned value.
> > On the other hand, i do use assignment in Python, and you seem to
> > propose to get rid of assignment or to break it.
> I thought the proposal was clear and succinct. "When [lambda
> are directly assigned to a variable, Python would use the variable
> name as
> the function name." That's all. I don't know where you got the idea I
> proposing "to get rid of assignment".
I suppose we use the term "assignment operation" differently. By
assignment i mean evaluating the expressions in the right-hand side and
assigning (binding?) the value to the variable or location described in
the left-hand side. I believed this was the usual meaning of
The behaviour you describe cannot happen during assignment in this
> Maybe it was from my talk of implementing this by replacing the
> with an equivalent def statement in the AST. Bear in mind that the def
> statement is already just a particular kind of assignment: it creates
> function and assigns it to a name. The only difference between the
> assignment and the def statement that replaces it is in the __name__
> attribute of the function object that gets created. The proposal just
> the direct lambda assignment and the def "assignment" to be fully
`def` is not an assignment, it is more than that.