Author yselivanov
Recipients gvanrossum, ncoghlan, skrah, vstinner, yselivanov
Date 2015-07-21.13:33:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1437485590.3.0.905180398165.issue24619@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry for not responding earlier, I'm on vacation and don't check email too often.

While investigating what can be done in tokenizer.c to fix some of the bugs that Stefan pointed out, I discovered a simpler approach: instead of checking what kind of function we have on top of the stack, I now have a counter of nested async functions.  This aligns nicely with what Nick said on python-dev once: we essentially treat 'async def' as a future import, everything inside it parses differently.

In other words, before this patch:

   async def foo():
       def bar():
           async = 1

was legal, now it's a syntax error, as 'async' will be parsed as 'ASYNC' token.

This simplifies the implementation of tokenizer.c hacks, fixes all of the bugs that Stefan posted here, *and* enables one-line 'async' functions:

   async def foo(): await bar() # legal with the patch

It will also help with migrating the code to Python 3.7 when async/await will become proper keywords.

And, with this patch we can effectively remove the shortcomings section from the PEP 492 (https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings).

Please review the attached patch, it would be great if we can commit it before 3.5beta4.
History
Date User Action Args
2015-07-21 13:33:10yselivanovsetrecipients: + yselivanov, gvanrossum, ncoghlan, vstinner, skrah
2015-07-21 13:33:10yselivanovsetmessageid: <1437485590.3.0.905180398165.issue24619@psf.upfronthosting.co.za>
2015-07-21 13:33:10yselivanovlinkissue24619 messages
2015-07-21 13:33:09yselivanovcreate