Syntax for one-line "nonymous" functions in "declaration style"
alexey.muranov at gmail.com
Mon Apr 1 17:52:41 EDT 2019
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>
>> On dim., Mar 31, 2019 at 6:00 PM, python-list-request at python.org
>> > 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
>> >> > that,
>> >> > when they are directly assigned to a variable, Python would
>> >> the
>> >> > variable name as the function name. I expect this could be
>> >> > accomplished by
>> >> > a straightforward transformation of the AST, perhaps even by
>> >> > 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
>> >> 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
>> it breaks simple rules.
>> I do not like 0-argument `super()` either, but at least I do not
>> to use it.
> Well, you wouldn't have to use my suggestion either, since it only
> 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
> 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.
foo.bar = baz
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
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
f = lambda x: x,
g = lambda x: x*x
(f, g) = (lambda x: x, lambda x: x*x)
(f, g) = _ = (lambda x: x, lambda x: x*x)
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>
result = lambda x: <some long expression>
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
> def statements?
It is not fixing, it is breaking.
More information about the Python-list