On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov <alexey.mura...@gmail.com>
wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.
No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid readability at
a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.
> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.
I thought the proposal was clear and succinct. "When [lambda expressions]
are directly assigned to a variable, Python would use the variable name as
the function name." That's all. I don't know where you got the idea I was
proposing "to get rid of assignment".
Maybe it was from my talk of implementing this by replacing the assignment
with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates a
function and assigns it to a name. The only difference between the original
assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just makes
the direct lambda assignment and the def "assignment" to be fully
equivalent.
> Note that
>
> foo.bar = baz
>
> and
>
> foo[bar] = baz
I wrote "directly assigned to a variable", not to an attribute or an item.
These are not part of the suggestion.
> 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
No, this is entirely unrelated to what I suggested.
> I am so perplexed by the proposed behaviour of `f = lambda...`, that i
> need to ask the followng: am i right to expact that
I'm not going to address what these would do because I haven't developed
the idea to this level of detail, nor do I intend to. It was just an idea
put forth to address the complaint that lambda functions assigned to
variables don't get properly named, as well as the obstacle that the
proposed "f(x) = ..." syntax not only explicitly refuses to address this,
but potentially makes the problem worse by making lambda assignment more
attractive without doing anything to actually name them. I have no
expectation of writing a PEP for it.
> 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.
Correct, the first would return a function with the name "<lambda>" (as it
does now), while the second would return a function with the name "result".
Whether or not that is more useful than "<lambda>" in this case is up to
the reader.
> 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.
I'm fairly sure the language would continue to function just fine. It
creates a gotcha to be sure, but it's far from being the only one, or even
the biggest one that has to do with lambdas (that award surely goes to the
behavior of lambda closures created in a loop, which comes up on this list
with some regularity).
--
https://mail.python.org/mailman/listinfo/python-list
