<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-04-15 6:08 GMT+03:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@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>
It's not completely off topic. as it's due to the fact we use "," to<br>
separate both context managers and items in a tuple, so "with (cm1,<br>
cm2, cm3):" is currently legal syntax that means something quite<br>
different from "with cm1, cm2, cm3:". While using the parenthesised<br>
form is *pointless* (since it will blow up at runtime due to tuples<br>
not being context managers), the fact it's syntactically valid makes<br>
us more hesitant to add the special case around parentheses handling<br>
than we were for import statements. The relevance to PEP 572 is as a<br>
reminder that since we *really* don't like to add yet more different<br>
cases to "What do parentheses indicate in Python?"</blockquote><div><br></div><div>Despite the fact that
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">"with (cm1,</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">cm2, cm3):"</span>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">currently</span>
is the legal syntax, but as you said and as it was also noted before in this thread - it is "pointless" in 99% cases (in context of with statement) and will fail at runtime. Therefore, regardless of this PEP, maybe it is fair to make it at least to be a `SyntaxWarning` (or `SyntaxError`)? Better fail sooner than later. </div><div><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">we should probably<br>
show similar hesitation when it comes to giving ":" yet another<br>
meaning.<br>
<br></blockquote><div><br></div><div>Yes, `:` is used (as a symbol) in a lot of places (in fact there is not much in it), but in some places Python looks as a combination of words and colons. </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">P.S. The pros and cons of the current syntax proposals, as I see them:<br>
<br>
=== Expression first, 'as' keyword ===<br>
<br>
while (read_next_item() as value) is not None:<br>
...<br>
<br>
Pros:<br>
<br>
* typically reads nicely as pseudocode<br>
* "as" is already associated with namebinding operations<br>
<br></blockquote><div><br></div><div>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I understand that this list is subjective. But as for me it will be huge PRO that the expression comes first. </span><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">
Cons:<br>
<br>
* syntactic ambiguity in with statement headers (major concern)<br>
* encourages a common misunderstanding of how with statements work<br>
(major concern)<br>
* visual similarity between "as" and "and" makes name bindings easy to miss<br>
* syntactic ambiguity in except clause headers theoretically exists,<br>
but is less of a concern due to the consistent type difference that<br>
makes the parenthesised form pointless<br>
<br></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">In reality,</span> the first two points can be explained (if it will be required at all). Misunderstanding is a consequence of a lack of experience. I don't understand the the point about "<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">visual similarity between "as" and "and" can you elaborate on this point a little bit more?</span></div><div><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">
=== Expression first, '->' symbol ===<br>
<br>
while (read_next_item() -> value) is not None:<br>
...<br>
<br>
Pros:<br>
<br>
* avoids the syntactic ambiguity of "as"<br>
* "->" is used for name bindings in at least some other languages<br>
(but this is irrelevant to users for whom Python is their first, and<br>
perhaps only, programming language)<br>
<br></blockquote><div><br></div><div>The same as previous,
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">the expression comes first is a huge PRO for me and I'm sure for many others too. With the second point I agree that it is somewhat irrelevant. </span></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">
Cons:<br>
<br>
* doesn't read like pseudocode (you need to interpret an arbitrary<br>
non-arithmetic symbol)<br></blockquote><div><br></div><div>Here I am a bit disagree with you. The most common for of assignment in formal pseudo-code is `name <- expr`. The second most common form, to my regret,
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">is - `:=`. The `<-` form is not possible in Python and that is why `expr -> name` was suggested. </span></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">
* invites the question "Why doesn't this use the 'as' keyword?"<br></blockquote><div><br></div><div>All forms invites this question :)))</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">
* symbols are typically harder to look up than keywords<br>
* symbols don't lend themselves to easy mnemonics<br>
* somewhat arbitrary repurposing of "->" compared to its use in<br>
function annotations<br><br></blockquote><div> The last one is a <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">major concern. I think that is why Guido is so skeptical about this form.</span></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">
=== Target first, ':=' symbol ===<br>
<br>
while (value := read_next_item()) is not None:<br>
...<br>
<br>
Pros:<br>
<br>
* avoids the syntactic ambiguity of "as"<br>
* being target first provides an obvious distinction from the "as" keyword<br></blockquote><div><br></div><div>For me it is a CON. Originally the rationale of this PEP was to reduce the number of unnecessary calculations and to provide a useful syntax to make a name binding in appropriate places. It should not, in any way, replace the existing `=` usual way to make a name binding. Therefore, as I see it, it is one of design goals to make the syntax forms of `assignment statement` and `assignment expression` to be distinct and `:=` does not help with this. This does not mean that this new syntax form should not be convenient, but it should be different from the usual `=` form.</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">
* ":=" is used for name bindings in at least some other languages<br>
(but this is irrelevant to users for whom Python is their first, and<br>
perhaps only, language)<br>
<br>
Cons:<br>
<br>
* symbols are typically harder to look up than keywords<br>
* symbols don't lend themselves to easy mnemonics<br>
* subject to a visual "line noise" phenomenon when combined with<br>
other uses of ":" as a syntactic marker (e.g. slices, dict key/value<br>
pairs, lambda expressions, type annotations)<br></blockquote><div><br></div><div>Totally agree with the last point!</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">
<br>
<br>
=== Target first, 'from' keyword ===<br>
<br>
while (value from read_next_item()) is not None: # New<br>
...<br>
<br>
Pros:<br>
<br>
* avoids the syntactic ambiguity of "as"<br>
* being target first provides an obvious distinction from the "as" keyword<br></blockquote><div><br></div><div>As above.</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">
* typically reads nicely as pseudocode<br></blockquote><div><br></div><div>As for me this form implies _extraction_+binding (finding inside + binding) instead of just binding. </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">
* "from" is already associated with a namebinding operation ("from<br>
module import name")<br></blockquote><div><br></div><div>but module is a namespace, and `from` means _extract_ and bind.</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">
<br>
Cons:<br>
<br>
* I'm sure we'll think of some more, but all I have so far is that<br>
the association with name binding is relatively weak and would need to<br>
be learned<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>With kind regards,</div><div>-gdg </div></div></div></div>