On Sat, Apr 14, 2018 at 12:50 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Fri, Apr 13, 2018 at 02:30:24PM +0100, Paul Moore wrote:
>> On 13 April 2018 at 14:18, Steven D'Aprano <st...@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.

Then we're talking about unrelated points, and "currently-allowed" is

> 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.

That part isn't at all in question. The meaning of "with expr as
name:" MUST NOT change, because that would massively break backward

> 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.

For that to work, the assignment expression MUST be disallowed in the
header of a 'with' statement. Which is one of the suggestions I made.
In fact, it was the PEP's recommendation as of the last point when
'as' was the preferred syntax. I never got as far as implementing
that, but it'd be the safest solution. And it's still a special case.

> (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.)

Definitely not; again, that would break backward compatibility. We are
in agreement on that.

> 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.

Then it HAS to be a SyntaxError. Because that's what it means now. Or
are you saying "it means the same thing it would mean now if the
parentheses were omitted"? Because that is definitely not an easy
thing to explain.

> 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*

Funnily enough, that's my stance too. I guess we're all just wrong,
wronger, and wrongest today :)

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to