<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 05.07.2018 2:29, Nathaniel Smith wrote:<br>
<blockquote type="cite"
cite="mid:CAPJVwBmdjua-h7dgbmuhxns=sh5eRXOdYQT9SpBD4ExyxuxCtw@mail.gmail.com">
<pre wrap="">On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
<a class="moz-txt-link-rfc2396E" href="mailto:python-dev@python.org"><python-dev@python.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 04.07.2018 10:10, Nathaniel Smith wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Right, Python has a *very strong* convention that each line should
have at most one side-effect, and that if it does have a side-effect
it should be at the outermost level.
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I think the most striking evidence for this is that during the
discussion of PEP 572 we discovered that literally none of us –
including Guido – even *know* what the order-of-evaluation is inside
expressions. In fact PEP 572 now has a whole section talking about the
oddities that have turned up here so far, and how to fix them. Which
just goes to show that even its proponents don't actually think that
anyone uses side-effects inside expressions, because if they did, then
they'd consider these changes to be compatibility-breaking changes. Of
course the whole point of PEP 572 is to encourage people to embed
side-effects inside expressions, so I hope they've caught all the
weird cases, because even if we can still change them now we won't be
able to after PEP 572 is implemented.
</pre>
</blockquote>
<pre wrap="">
I may have a fix to this:
Do not recommend assigning to the variable that is used later in the
expression.
</pre>
</blockquote>
<pre wrap="">
This would rule out all the comprehension use cases.</pre>
</blockquote>
Only those outside of the outermost iterable.<br>
<blockquote type="cite"
cite="mid:CAPJVwBmdjua-h7dgbmuhxns=sh5eRXOdYQT9SpBD4ExyxuxCtw@mail.gmail.com">
<pre wrap="">
I'd be fine with that personally. Reading through the PEP again I see
that there are more examples of them than I previously realized,
inside the semantics discussion and... well, this may be a personal
thing but for me they'd all be better described as "incomprehensions".
</pre>
</blockquote>
<blockquote type="cite"
cite="mid:CAPJVwBmdjua-h7dgbmuhxns=sh5eRXOdYQT9SpBD4ExyxuxCtw@mail.gmail.com">
<pre wrap="">
But, nonetheless, the comprehension use cases are supposed to be a
core motivation for the whole PEP.</pre>
</blockquote>
<br>
Far from it. If/while, too. Any construct that accepts an expression
and uses its result but doesn't allow to insert an additional line
in the middle qualifies.<br>
<blockquote type="cite"
cite="mid:CAPJVwBmdjua-h7dgbmuhxns=sh5eRXOdYQT9SpBD4ExyxuxCtw@mail.gmail.com">
<pre wrap="">Also, some of the main arguments
for why a full-fledged := is better than the more limited alternative
proposals rely on using a variable on the same line where it's
assigned (e.g. Tim's gcd example). So I don't see this recommendation
getting any official traction within PEP 572 or PEP 8.
</pre>
</blockquote>
That's actually a valid use case!<br>
In the aforementioned example,<br>
<pre class="literal-block">if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g</pre>
the variable `diff' doesn't exist before, so there's no confusion
which value is used.<br>
<br>
<br>
Okay, I stay corrected:<br>
<br>
_Do not recommend *changing* a variable that is used later in the
expression._<br>
<br>
I.e. the variable should not exist before assignment (or effectively
not exist -- i.e. the old value should not be used).<br>
<br>
<br>
E.g., good:<br>
<br>
[ rem for x in range(10) if rem := x%5 ]<br>
<br>
bad:<br>
<br>
[ sum_ for x in range(10) if (sum_ := sum_ + x) % 5 ] # good
luck figuring out what sum_ will hold<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAPJVwBmdjua-h7dgbmuhxns=sh5eRXOdYQT9SpBD4ExyxuxCtw@mail.gmail.com">
<pre wrap="">
Of course you're free to use whatever style rules you prefer locally –
python-dev has nothing to do with that.
-n
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>