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

[Terry Reedy]

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.  I wrote 
and use a test function something like the following, simplified and 
adapted for use with unittest:

def ftest(func, io_pairs):
     errors = []
     for input, expected in io_pairs:
         actual = func(input)
         if actual != expected:
             errors.append(
                     f"Func: {func.__name__}, input: {input}, "
                     f"expected: {expected}, actual: {actual}.")
     return errors if errors else None

(Then "self.assertNone(ftest(func, io_pairs))" will test all pairs and 
list at least part of the error list.)

If all the names were '<lambda>', not very useful.  (The workaround 
would be to require the caller to know a name and pass it separately, 
without mis-typing.)

for unittest, a


> 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

For attributes, "def C.double(x): return x*x" has been proposed but not 
accepted.