<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 04.07.2018 10:10, Nathaniel Smith wrote:<br>
<blockquote type="cite"
cite="mid:CAPJVwBkjGXh3eYz2Auh+m2q--Ai7qCqp=hyqc5c5W+SvV+n3jg@mail.gmail.com">
<pre wrap="">On Tue, Jul 3, 2018 at 11:07 PM, Serhiy Storchaka <a class="moz-txt-link-rfc2396E" href="mailto:storchaka@gmail.com"><storchaka@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">04.07.18 00:51, Chris Angelico пише:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka <a class="moz-txt-link-rfc2396E" href="mailto:storchaka@gmail.com"><storchaka@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I believe most Python users are not
professional programmers -- they are sysadmins, scientists, hobbyists and
kids --
</pre>
</blockquote>
<pre wrap="">
[citation needed]
</pre>
</blockquote>
<pre wrap="">
I don't understand what citation do you need.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In particularly mutating and
non-mutating operations are separated. The assignment expression breaks
this.
</pre>
</blockquote>
<pre wrap="">
[citation needed]
</pre>
</blockquote>
<pre wrap="">
In Python the assignment (including the augmented assignment) is a
statement, del is a statement, function and class declarations are
statements, import is a statement. Mutating methods like list.sort() and
dict.update() return None to discourage using them in expressions. This a
common knowledge, I don't know who's citation you need.
</pre>
</blockquote>
<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.
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>
<p>I may have a fix to this:</p>
<p>Do not recommend assigning to the variable that is used later in
the expression.</p>
<p>And to facilitate that, do not make any strong guarantees about
evaluation order -- making any such attempt a gamble.<br>
</p>
<p>I immediately saw those "total := total + item" as odd but
couldn't quite point out why.<br>
Now I see: it ignores the whole augmented assignment machinery
thing, which will make people demand that next.<br>
Making this a discouraged case will diminish valid use cases and
lower the need for that.<br>
</p>
<blockquote type="cite"
cite="mid:CAPJVwBkjGXh3eYz2Auh+m2q--Ai7qCqp=hyqc5c5W+SvV+n3jg@mail.gmail.com">
<pre wrap="">Some people make fun of Python's expression/statement dichotomy,
because hey don't you know that everything can be an expression,
functional languages are awesome hurhur, but I think Python's approach
is actually very elegant. Python is unapologetically an imperative
language, but even we dirty imperative programmers can agree with the
functional fanatics that reasoning about side-effects and sequencing
is hard. One-side-effect-per-line is a very elegant way to keep
sequencing visible on the page and as easy to reason about as
possible.
Or as Dijkstra put it: "our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed. For that reason we
should do (as wise programmers aware of our limitations) our utmost to
shorten the conceptual gap between the static program and the dynamic
process, to make the correspondence between the program (spread out in
text space) and the process (spread out in time) as trivial as
possible."
It's very disheartening that not only is PEP 572 apparently going to
be accepted, but as far as I can tell neither the text nor its
proponents have even addressed this basic issue.
-n
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>