[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Syntax for one-line "nonymous" functions in "declaration style"

> On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov <alexey.muranov at 
> wrote:
> >
> > 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 
> expressions]
> 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 
> was
> 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 
> assignment
> 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 
> a
> function and assigns it to a name. The only difference between the 
> original
> assignment and the def statement that replaces it is in the __name__
> attribute of the function object that gets created. The proposal just 
> makes
> the direct lambda assignment and the def "assignment" to be fully
> equivalent.

`def` is not an assignment, it is more than that.