On lun., avril 1, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov
<alexey.mura...@gmail.com>
wrote:
On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org
wrote:
> On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov
> <alexey.mura...@gmail.com>
> wrote:
>
>>
>> On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@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.
--
https://mail.python.org/mailman/listinfo/python-list
