[Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
Kirill Balunov
kirillbalunov at gmail.com
Mon Apr 16 08:35:33 EDT 2018
[Guido]
2018-04-15 20:19 GMT+03:00 Guido van Rossum <guido at python.org>:
> On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov <kirillbalunov at gmail.com>
> wrote:
>
>> [...] For me personally, `: =` looks and feels just like normal
>> assignment statement which can be used interchangeable but in many more
>> places in the code. And if the main goal of the PEP was to offer this
>> `assignment expression` as a future replacement for `assignment statement`
>> the `:=` syntax form would be the very reasonable proposal (of course in
>> this case there will be a lot more other questions).
>>
>
> I haven't kept up with what's in the PEP (or much of this thread), but
> this is the key reason I strongly prefer := as inline assignment operator.
>
>
>> But somehow this PEP does not mean it! And with the current rationale of
>> this PEP it's a huge CON for me that `=` and `:=` feel and look the same.
>>
>
> Then maybe the PEP needs to be updated.
>
[Chris]
2018-04-15 23:28 GMT+03:00 Chris Angelico <rosuav at gmail.com>:
> On Mon, Apr 16, 2018 at 3:19 AM, Guido van Rossum <guido at python.org>
> wrote:
> > On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov <kirillbalunov at gmail.com
> >
> > wrote:
> >> But somehow this PEP does not mean it! And with the current rationale of
> >> this PEP it's a huge CON for me that `=` and `:=` feel and look the
> same.
> >
> > Then maybe the PEP needs to be updated.
>
> I can never be sure what people are reading when they say "current"
> with PEPs like this. The text gets updated fairly frequently. As of
> time of posting, here's the rationale:
>
> -----
> Naming the result of an expression is an important part of programming,
> allowing a descriptive name to be used in place of a longer expression,
> and permitting reuse. Currently, this feature is available only in
> statement form, making it unavailable in list comprehensions and other
> expression contexts. Merely introducing a way to assign as an expression
> would create bizarre edge cases around comprehensions, though, and to avoid
> the worst of the confusions, we change the definition of comprehensions,
> causing some edge cases to be interpreted differently, but maintaining the
> existing behaviour in the majority of situations.
> -----
>
> Kirill, is this what you read, and if so, how does that make ':=' a
> negative? The rationale says "hey, see this really good thing you can
> do as a statement? Let's do it as an expression too", so the parallel
> should be a good thing.
>
>
Yes, this is what I read. I understand why you have such a question so I'll
try to explain my position in more detail. Also I want to add that I did
not fully understand about which part Guido said - "Then maybe the PEP
needs to be updated." Therefore, I allow myself to assume that he had in
mind the following - "The assignment expression should be semantically
equivalent to assignment statement and perceived as a theoretically
possible future replacement (usage) of assignment statement." If this is
really the case and I understood correctly - I will repeat that for me the
current state of the PEP does not fully imply this.
1. Part - "Then maybe the PEP needs to be updated."
If you really see it as a theoretical substitute for assignment statement
in future Python. I will update the rationale with maybe the following (I
immediately warn you that I do not pretend to have a good English style):
-----
Naming the result of an expression is an important part of programming,
allowing a descriptive name to be used in place of a longer expression,
and permitting reuse. Currently, in Python this feature is available only
in
statement form, making it unavailable in list comprehensions and other
expression contexts. This restriction, of making it as a statement, was
done
primarily to avoid the usual trap of `=` vs `==` in C/C++ language. Despite
this, it is evident that the ability to assign a name within an expression
is convenient, allows to avoid redundant recalculations of the same
expression
and is a familiar feature from other programming languages. Thus the main
aim
of this PEP is to provide a syntax which will allow to assign as an
expression
and be semantically and visually interchangeable with the assignment
statement.
...
-----
In this case, I do not see any reason to discuss the alternative syntax -
there is really only one choice `:=`. And then for me the list of open
questions would look like (for example):
1. ...Is it worth accepting?
2. ...Should the other forms (+=, *=, basically all) that can not be
confused with `==` be changed to expressions?
...
2. Part - How do I understand the current state of the PEP
I perceive the current rationale as "hey, see this really good thing you
can do as a statement? Let's do it as an expression too". Which for me
means opportunities to discuss the following questions:
1. Should assignment expression be viewed as a replacement of an
assignment statement or as a complement to it?
2. Which spelling should have an assignment expression? ( depends on the
previous )
3. Does it make sense to make it valid only in certain context or in any?
... and many others ...
You are the author of this PEP. Therefore, you choose how you take it, how
you feel it and what kind of feedback you are willing to accept, and in any
case I will respect your choice :)
with kind regards,
-gdg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180416/d934ea26/attachment-0001.html>
More information about the Python-ideas
mailing list