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.
Just throwing this idea in: what about an approach _not touching_ the parser or compiler at all? : Just add __enter__ and __exit__ to tuples themselves! Instead of repeating "why should we ever do that", we _do_ that exactly to enter the contexts in all tuple elements, and leave then in order.
On Thu, 14 Nov 2019 at 17:08, Andrew Barnert via Python-ideas < email@example.com> wrote:
On Nov 14, 2019, at 10:33, Guido van Rossum firstname.lastname@example.org 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@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/BEQRGP... Code of Conduct: http://python.org/psf/codeofconduct/