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

[Alexey Muranov]

On lun., avril 1, 2019 at 6:00 PM, python-list-request at python.org wrote:
> On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov 
> <alexey.muranov at gmail.com>
> wrote:
>> 
>>  On dim., Mar 31, 2019 at 6:00 PM, python-list-request at python.org 
>> wrote:
>>  > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov
>>  > <alexey.muranov at gmail.com>
>>  > wrote:
>>  >
>>  >>
>>  >>  On ven., Mar 29, 2019 at 4:51 PM, python-list-request at python.org
>>  >> wrote:
>>  >>  >
>>  >>  > There could perhaps be a special case for lambda expressions 
>> such
>>  >>  >  that,
>>  >>  > when they are directly assigned to a variable, Python would 
>> use
>>  >> the
>>  >>  > variable name as the function name. I expect this could be
>>  >>  >  accomplished by
>>  >>  > a straightforward transformation of the AST, perhaps even by 
>> just
>>  >>  >  replacing
>>  >>  > the assignment with a def statement.
>>  >>
>>  >>  If this will happen, that is, if in Python assigning a
>>  >> lambda-defined
>>  >>  function to a variable will mutate the function's attributes, or
>>  >> else,
>>  >>  if is some "random" syntactically-determined cases
>>  >>
>>  >>      f = ...
>>  >>
>>  >>  will stop being the same as evaluating the right-hand side and
>>  >>  assigning the result to "f" variable, it will be a fairly good 
>> extra
>>  >>  reason for me to go away from Python.
>>  >>
>>  >
>>  > Is there a particular reason you don't like this? It's not too
>>  > different
>>  > from the syntactic magic Python already employs to support the
>>  > 0-argument
>>  > form of super().
>> 
>>  I do not want any magic in a programming language i use, especially 
>> if
>>  it breaks simple rules.
>> 
>>  I do not like 0-argument `super()` either, but at least I do not 
>> have
>>  to use it.
> 
> Well, you wouldn't have to use my suggestion either, since it only 
> applies
> to assignments of the form "f = lambda x: blah". As has already been
> stated, the preferred way to do this is with a def statement. So just 
> use a
> def statement for this, and it wouldn't affect you (unless you 
> *really*
> want the function's name to be "<lambda>" for some reason).

I only see a superficial analogy with `super()`, but perhaps it is 
because you did not give much details of you suggestion.

Not only i do not have to use `super()` (i do not have to use Python 
either), but the magic behaviour of `super` is explained by special 
implicit environments in which some blocks of code are executed.  
Though this looks somewhat hackish, it gives me no clue of how your 
idea of mutating objects during assignment is supposed to work.

On the other hand, i do use assignment in Python, and you seem to 
propose to get rid of assignment or to break it.

Note that

    foo.bar = baz

and

    foo[bar] = baz

are not assignments but method calls, but

    foo = bar

it an assignment (if i understand the current model correctly).

Do you propose to desugar it into a method/function call and to get rid 
of assignments in the language completely? Will the user be able to 
override this method? Something like:

    setvar("foo", bar)  # desugaring of foo = bar

Would the assignment operation remain in the language under a different 
name?  Maybe,

    foo <- bar

?

I am so perplexed by the proposed behaviour of `f = lambda...`, that i 
need to ask the followng: am i right to expact that

  1.

      f = lambda x: x,
      g = lambda x: x*x

  2.

      (f, g) = (lambda x: x, lambda x: x*x)

  3.

      (f, g) = _ = (lambda x: x, lambda x: x*x)

  4.

      f = (lambda x: x)(lambda x: x)
      g = (lambda x: x)(lambda x: x*x)

Will all have the same net effect?

I suppose in any case that

    return lambda x: <some long expression>

and

    result = lambda x: <some long expression>
    return result

would not return the same result, which is not what i want.

I tried to imagine what semantics of the language could cause your 
proposed behaviour of `f = lambda...` and couldn't think of anything 
short of breaking the language.


> That said, that's also the reason why this probably wouldn't happen. 
> Why go
> to the trouble of fixing people's lambda assignments for them when the
> preferred fix would be for them to do it themselves by replacing them 
> with
> def statements?

It is not fixing, it is breaking.

Alexey.