<div dir="ltr">Great work Chris! Thank you!<br><br>
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-"><span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">I do not know
whether this is good or bad, but this PEP considers so many different
topics,<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-"><span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">
<span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">although closely interrelated with each other.</span></span></span></span></span></span></span></span>
</span></span>
<br><div class="gmail_extra"><br><div class="gmail_quote">2018-04-11 8:32 GMT+03:00 Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Alterations to comprehensions<br>
-----------------------------<br>
<br>
The current behaviour of list/set/dict comprehensions and generator<br>
expressions has some edge cases that would behave strangely if an assignment<br>
expression were to be used. Therefore the proposed semantics are changed,<br>
removing the current edge cases, and instead altering their behaviour *only*<br>
in a class scope.<br>
<br>
As of Python 3.7, the outermost iterable of any comprehension is evaluated<br>
in the surrounding context, and then passed as an argument to the implicit<br>
function that evaluates the comprehension.<br>
<br>
Under this proposal, the entire body of the comprehension is evaluated in<br>
its implicit function. Names not assigned to within the comprehension are<br>
located in the surrounding scopes, as with normal lookups. As one special<br>
case, a comprehension at class scope will **eagerly bind** any name which<br>
is already defined in the class scope.<br>
<br></blockquote><div><br></div><div>I think this change is important one no matter what will be the future of the current PEP. And since it breaks backward compatibility it deserves a separate PEP. <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Open questions<br>
==============<br>
<br>
Can the outermost iterable still be evaluated early?<br>
------------------------------<wbr>----------------------<br>
<br>
As of Python 3.7, the outermost iterable in a genexp is evaluated early, and<br>
the result passed to the implicit function as an argument. With PEP 572, this<br>
would no longer be the case. Can we still, somehow, evaluate it before moving<br>
on? One possible implementation would be::<br>
<br>
gen = (x for x in rage(10))<br>
# translates to<br>
def <genexp>():<br>
iterable = iter(rage(10))<br>
yield None<br>
for x in iterable:<br>
yield x<br>
gen = <genexp>()<br>
next(gen)<br>
<br>
This would pump the iterable up to just before the loop starts, evaluating<br>
exactly as much as is evaluated outside the generator function in Py3.7.<br>
This would result in it being possible to call ``gen.send()`` immediately,<br>
unlike with most generators, and may incur unnecessary overhead in the<br>
common case where the iterable is pumped immediately (perhaps as part of a<br>
larger expression).<br>
<br></blockquote><div><br></div><div>Previously, there was an alternative _operator form_
`->` <span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-"> proposed</span></span> by Steven D'Aprano. <span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">This option is no longer considered</span></span>?
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">I see several advantages with this variant</span></span>:<br></div><div>1. It does not use `:` symbol which is
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">very visually overloaded</span></span>
in Python.<br></div><div>2.
It is clearly distinguishable from the usual assignment statement and it's `+=` friends<br></div><div>There are others but they are minor.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Frequently Raised Objections<br>
============================<br>
<br>
Why not just turn existing assignment into an expression?<br>
------------------------------<wbr>---------------------------<br>
<br>
C and its derivatives define the ``=`` operator as an expression, rather than<br>
a statement as is Python's way. This allows assignments in more contexts,<br>
including contexts where comparisons are more common. The syntactic similarity<br>
between ``if (x == y)`` and ``if (x = y)`` belies their drastically different<br>
semantics. Thus this proposal uses ``:=`` to clarify the distinction.<br>
<br>
<br>
This could be used to create ugly code!<br>
------------------------------<wbr>---------<br>
<br>
So can anything else. This is a tool, and it is up to the programmer to use it<br>
where it makes sense, and not use it where superior constructs can be used.<br>
<br></blockquote><div><br></div><div>But the ugly code matters,
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">especially when it comes to Python</span></span>.
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">For me, the ideal option would be</span></span> the combination of two rejected parts: <br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Special-casing conditional statements<br>
------------------------------<wbr>-------<br><br>
One of the most popular use-cases is ``if`` and ``while`` statements. Instead<br>
of a more general solution, this proposal enhances the syntax of these two<br>
statements to add a means of capturing the compared value::<br><br>
if re.search(pat, text) as match:<br>
print("Found:", match.group(0))<br><br>
This works beautifully if and ONLY if the desired condition is based on the<br>
truthiness of the captured value. It is thus effective for specific<br>
use-cases (regex matches, socket reads that return `''` when done), and<br>
completely useless in more complicated cases (eg where the condition is<br>
``f(x) < 0`` and you want to capture the value of ``f(x)``). It also has<br>
no benefit to list comprehensions.<br><br>
Advantages: No syntactic ambiguities. Disadvantages: Answers only a fraction<br>
of possible use-cases, even in ``if``/``while`` statements.
<br></blockquote>
</div></div><br><br></div><div class="gmail_extra">(+ in `while`) combined
with
this part:<br><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. ``with EXPR as NAME``::<br><br>
stuff = [(y, x/y) with f(x) as y for x in range(5)]<br><br>
As per option 2, but using ``as`` rather than an equals sign. Aligns<br>
syntactically with other uses of ``as`` for name binding, but a simple<br>
transformation to for-loop longhand would create drastically different<br>
semantics; the meaning of ``with`` inside a comprehension would be<br>
completely different from the meaning as a stand-alone statement, while<br>
retaining identical syntax.
<br></blockquote>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I see no benefit to have the assignment expression in other places. And all your provided examples use `while` or `if` or some form of comprehension. I also see no problem with `if (re.search(pat, text) as match) is not None:..`.
<span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">What is the point of overloading language with expression that will be used only in `while` and `if` and will be rejected by style checkers in other places?</span></span>
<br><br></div><div class="gmail_extra">With kind regards,<br></div><div class="gmail_extra">-gdg<br>
</div></div>