On Nov 14, 2019, at 10:33, Guido van Rossum <[email protected]> wrote:
>
> I would not be a fan of this approach (even though I agree it's technically
> feasible). The problem is that if a user simply forgets the colon at the end
> of a line (surely a common mistake), the modified parser would produce a much
> more confusing error on a subsequent line.
Yeah, that’s what I meant about error reporting getting worse rather than
better.
Presumably it would be similar to this existing case:
a = (b+c
d = a*a
… where you get a SyntaxError on the second line, where the code looks
perfectly valid (because out of context it would be perfectly valid).
This is something that every novice runs into and gets confused by (usually
with a more complicated expression missing the close parens), but we all get
used to it and it stops bothering us. Would the same thing be true for colons?
I don’t know. And, even if it is, is the first-time hurdle a worse problem than
the one we’re trying to solve? Maybe.
> With the PEG parser we could support this:
>
> with (
> open("file1") as f1,
> open("file2") as f2,
> ):
> <code>
>
> But there would still be an ambiguity if it were to see
>
> with (
> lock1.acquire(),
> lock2.acquire(),
> ):
> <code>
>
> Is that a simple tuple or a pair of context managers that are not assigned to
> local variables? I guess we can make it the latter since a tuple currently
> fails at runtime, but the ice is definitely thin here.
Yeah, the tuple ambiguity is the first thing that comes up every time someone
suggests parens for with. To a human it doesn’t look ambiguous, because how
could you ever want to use a tuple literal as a context manager, but the
question is whether you can make it just as unambiguous to the parser without
making the parser to complicated to hold in your head.
I think it could be done with the current parser, but only by making with_item
not use expression and instead use a expression-except-tuple production, but
that would require a couple dozen parallel sub productions to build up to that
one, which sounds like a terrible idea. And I’m not even 100% sure it would
work (because it still definitely needs to allow other parenthesized forms,
just not parenthesized tuples).
I think it could also be done by letting the grammar parse it as a tuple and
then having an extra (non-declarative) fixup step. But that obviously makes
parsing more complicated to think through, and to document, etc.
If it’s easy to do with a PEG parser, and if there are independent reasons to
switch to a PEG parser, maybe that’s ok? I don’t know. It is still more
complicated conceptually to have a slot in the grammar that’s “any expression
except a parenthesized tuple”.
That’s why I thought random’s suggestion of just allowing compound statement
headers to be multiline without requiring parens seemed potentially more
promising than the original (and frequent) suggestion to add parens here.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/BEQRGPL3SKEYB4FZXAUCFVYR5MROEQBJ/
Code of Conduct: http://python.org/psf/codeofconduct/
