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

[Alexey Muranov]

On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/28/2019 12:29 PM, Alexey Muranov wrote:
>> On jeu., Mar 28, 2019 at 5:00 PM, python-list-request at python.org 
>> wrote:
>>> 
>>> So my opinion is that lambda expressions should only be used within 
>>> larger expressions and never directly bound.
>>> 
>>>> It would be however more convenient to be able to write instead 
>>>> just
>>>> 
>>>>     f(x) = x*x
>>> 
>>> Given my view above, this is, standing alone, strictly an 
>>> abbreviation of the equivalent def statement.  I am presuming 
>>> that a proper implementation would result in f.__name__ == 'f'.
>>> 
>> 
>> No, after some thought, i think it should be an abbreviation of "f = 
>> lambda x: x*x", f.__name__ would still be '<lambda>'.
> 
> Throwing the name away is foolish.  Testing functions is another 
> situation in which function names are needed for proper report.

My idea however was to have it as an exact synonyme of an assignment of 
a lambda. Assignment is an assignment, it should not modify the 
attributs of the value that is being assigned.

> 
>> But i see your point about never assigning lambdas directly, it 
>> makes sense.  But sometimes i do assign short lambdas directly to 
>> variable.
>> 
>>> Is the convenience and (very low) frequency of applicability worth 
>>> the inconvenience of confusing the meaning of '=' and 
>>> complicating the implementation?
>>> 
>>>> I do not see any conflicts with the existing syntax.
>>> 
>>> It heavily conflicts with existing syntax.  The current meaning of
>>>   target_expression = object_expression
>>> is
>>> 1. Evaluate object_expression in the existing namespace to an 
>>> object, prior to any new bindings and independent of the 
>>> target_expression.
>>> 2. Evaluate target_expression in the existing namespace to one or 
>>> more targets.
>>> 3. Bind object to target or iterate target to bind to multiple 
>>> targets.
>> 
>> I do not thick so.  In "x = 42" the variable x is not evaluated.
>> 
>> All examples of the proposed syntax i can think of are currently 
>> illegal, so i suppose there is no conflicts. (I would appreciate a 
>> counterexample, if any.)
> 
> You are talking about syntax conflicts, I am talking about semantic 
> conflict, which is important for human understanding.
> 
>> Thanks for the reference to PEP 8, this is indeed an argument 
>> against.
> 
> The situation in which assigning lambda expressions is more tempting 
> is when assigning to attributes or dicts.
> 
> def double(x): return x*x
> C.double = double
> d['double'] = double
> versus
> 
> C.double = lambda x: x*x
> d['double'] = lambda x: x*x

These are some of examples i had in mind as well:

    C.double(x) = x*x
    d['double'](x) = x*x

Alexey.