[Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Steven D'Aprano]

On Fri, Apr 13, 2018 at 02:30:24PM +0100, Paul Moore wrote:
> On 13 April 2018 at 14:18, Steven D'Aprano <steve at pearwood.info> wrote:
> > On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
> 
> >> 2) Forbid any use of "(expr as name)" in the header of a 'with' statement
> >
> > You can't forbid it, because it is currently allowed syntax
> 
> It's not currently allowed:

It is without the parens, as I said:

[...]
> > (albeit currently without the parens).
> 
> Well, yes, but we're talking about *with* the parens.

You might be, but I'm not.

I'm talking about the conflict between:

    # pre-PEP 572 context manager
    with expr as name:

    # post-PEP 572, is it a context manager or an assignment expression?
    with expr as name:


and I'm saying, don't worry about the syntactical ambiguity, just make a 
ruling that it is a context manager, never an assignment expression.

I'm saying, don't even try to distinguish between the forms with or 
without parens. If we add parens:

    with (expr as name):

it may or may not be allowed some time in the future (since it isn't 
allowed now, but there are many requests for it) but if it is allowed, 
it will still mean a context manager and not assignment expression.

(In case it isn't obvious, I'm saying that we need not *require* parens 
for this feature, at least not if the only reason for doing so is to 
make the with/except case unambiguous.)


[...]
> (unless you argue in
> circles: it's worth being a special case because "as" is a good syntax
> for assignment expressions, and "as" is a good syntax because it's
> unambiguous...)

I never said that "as" was unambiguous. I just spent a rather long post 
attempting to explain how to deal with that ambiguity. Sorry if I was 
not clear enough. I'm saying we can deal with it by simply defining what 
we want it to mean, and using the surrounding context to distinguish the 
cases.

If it is in a with or except clause (just the header clause, not the 
following block) , then it means the same thing it means now. Everywhere 
else, it means assignment expression.

Just like "x = 1" can mean assignment, or it can mean a parameter 
declaration. We don't have different syntax for those two distinct 
actions, we simply state that if "x = 1" is inside a lambda or function 
def, then it always means a parameter declaration and never an illegal 
assignment.


> > If people agree with me that it is important to put the expression first
> > rather than the target name, then the fact that statements and for loops
> > put the name first shouldn't matter.
> 
> I agree that having the expression first is better. And I think that
> -> deserves consideration on that basis.

Indeed.


> I think "as" is *not* a good option for a "puts the expression first" 
> option, because of the ambiguities that Chris has explained.

I can see why people may dislike the "as" option. I think it comes down 
to personal taste. My aim is to set out what I see as a way around the 
with/except problem with a compromise:

- allow "expr as name" anywhere;
- require parentheses only to avoid syntactic ambiguity;
- and simply ban assignment expressions in with/except clauses and
  keep the existing with/except semantics.

I acknowledge that it isn't ideal, but compromises between conflicting 
requirements rarely are.

If people don't agree with me, you're all wrong, er, that is to say, I 
understand your position even if I disagree *wink*


-- 
Steve