2018-04-15 6:08 GMT+03:00 Nick Coghlan <ncoghlan@gmail.com>:

It's not completely off topic. as it's due to the fact we use "," to
separate both context managers and items in a tuple, so "with (cm1,
cm2, cm3):" is currently legal syntax that means something quite
different from "with cm1, cm2, cm3:". While using the parenthesised
form is *pointless* (since it will blow up at runtime due to tuples
not being context managers), the fact it's syntactically valid makes
us more hesitant to add the special case around parentheses handling
than we were for import statements. The relevance to PEP 572 is as a
reminder that since we *really* don't like to add yet more different
cases to "What do parentheses indicate in Python?"

Despite the fact that "with (cm1,cm2, cm3):"  currently 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. 


we should probably
show similar hesitation when it comes to giving ":" yet another
meaning.


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. 
 
P.S. The pros and cons of the current syntax proposals, as I see them:

=== Expression first, 'as' keyword ===

    while (read_next_item() as value) is not None:
        ...

Pros:

  * typically reads nicely as pseudocode
  * "as" is already associated with namebinding operations


I understand that this list is subjective. But as for me it will be huge PRO that the expression comes first. 
 
Cons:

  * syntactic ambiguity in with statement headers (major concern)
  * encourages a common misunderstanding of how with statements work
(major concern)
  * visual similarity between "as" and "and" makes name bindings easy to miss
  * syntactic ambiguity in except clause headers theoretically exists,
but is less of a concern due to the consistent type difference that
makes the parenthesised form pointless


In reality, 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 "visual similarity between "as" and "and" can you elaborate on this point a little bit more?

 
=== Expression first, '->' symbol ===

    while (read_next_item() -> value) is not None:
        ...

Pros:

  * avoids the syntactic ambiguity of "as"
  * "->" is used for name bindings in at least some other languages
(but this is irrelevant to users for whom Python is their first, and
perhaps only, programming language)


The same as previous,  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. 
 
Cons:

  * doesn't read like pseudocode (you need to interpret an arbitrary
non-arithmetic symbol)

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,  is - `:=`. The `<-` form is not possible in Python and that is why `expr -> name` was suggested. 
 
  * invites the question "Why doesn't this use the 'as' keyword?"

All forms invites this question :)))
 
  * symbols are typically harder to look up than keywords
  * symbols don't lend themselves to easy mnemonics
  * somewhat arbitrary repurposing of "->" compared to its use in
function annotations

 The last one is a major concern. I think that is why Guido is so skeptical about this form.
 
=== Target first, ':=' symbol ===

    while (value := read_next_item()) is not None:
        ...

Pros:

  * avoids the syntactic ambiguity of "as"
  * being target first provides an obvious distinction from the "as" keyword

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.
 
  * ":=" is used for name bindings in at least some other languages
(but this is irrelevant to users for whom Python is their first, and
perhaps only, language)

Cons:

  * symbols are typically harder to look up than keywords
  * symbols don't lend themselves to easy mnemonics
  * subject to a visual "line noise" phenomenon when combined with
other uses of ":" as a syntactic marker (e.g. slices, dict key/value
pairs, lambda expressions, type annotations)

Totally agree with the last point!
 


=== Target first, 'from' keyword ===

    while (value from read_next_item()) is not None: # New
        ...

Pros:

  * avoids the syntactic ambiguity of "as"
  * being target first provides an obvious distinction from the "as" keyword

As above.
 
  * typically reads nicely as pseudocode

As for me this form implies _extraction_+binding (finding inside + binding) instead of just binding. 
 
  * "from" is already associated with a namebinding operation ("from
module import name")

but module is a namespace, and `from` means _extract_ and bind.
 

Cons:

  * I'm sure we'll think of some more, but all I have so far is that
the association with name binding is relatively weak and would need to
be learned


With kind regards,
-gdg