> 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.
js
-><-
On Thu, 14 Nov 2019 at 17:08, Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Nov 14, 2019, at 10:33, Guido van Rossum <gu...@python.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 -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BEQRGPL3SKEYB4FZXAUCFVYR5MROEQBJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/6A2YKACBKKL2B3U66BRIHYDPRPVT2ZVW/
Code of Conduct: http://python.org/psf/codeofconduct/
