[issue24619] async/await parser issues

Changes by Yury Selivanov : -- stage: commit review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24619] async/await parser issues

Changes by Larry Hastings : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> commit review ___ Python tracker ___ ___ Python-bugs-list

[issue24619] async/await parser issues

Roundup Robot added the comment: New changeset d03f86e41066 by Yury Selivanov in branch '3.5': Issue #24619: Simplify async/await tokenization. https://hg.python.org/cpython/rev/d03f86e41066 New changeset 3f8048926690 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24619) https://hg.pyt

[issue24619] async/await parser issues

Yury Selivanov added the comment: Updated patch attached (rebased; minor optimization). I'll commit this patch in a few hours to make sure it lands in 3.5beta4. -- Added file: http://bugs.python.org/file39991/issue24619.4.patch ___ Python tracker <

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue24619] async/await parser issues

Yury Selivanov added the comment: > I'm just curious if the 'ctx' is still needed: It looks like > the outermost "async def" dominates all further nested scopes > w.r.t the tokenizer mode, no matter whether they're "def" or > "async def" scopes. This is a wonderful idea, that's the way it shoul

[issue24619] async/await parser issues

Stefan Krah added the comment: This is a very nice solution! I'm just curious if the 'ctx' is still needed: It looks like the outermost "async def" dominates all further nested scopes w.r.t the tokenizer mode, no matter whether they're "def" or "async def" scopes. IOW, a single indent_level va

[issue24619] async/await parser issues

Roundup Robot added the comment: New changeset e4e01488afff by Yury Selivanov in branch '3.5': Issue #24619: More tests; fix nits in compiler.c https://hg.python.org/cpython/rev/e4e01488afff New changeset 6f4e0c462daf by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24619) https://hg.pyt

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue24619] async/await parser issues

Changes by Yury Selivanov : -- stage: patch review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24619] async/await parser issues

Yury Selivanov added the comment: Thanks Nick! I've committed the patch with a few more unittests and a couple of additional comments in tokenizer.(c|h). -- resolution: -> fixed ___ Python tracker __

[issue24619] async/await parser issues

Roundup Robot added the comment: New changeset 9da080ecadb2 by Yury Selivanov in branch '3.5': Issue #24619: New approach for tokenizing async/await. https://hg.python.org/cpython/rev/9da080ecadb2 New changeset 987b72921a0c by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24619) https://

[issue24619] async/await parser issues

Nick Coghlan added the comment: Patch & test cases look good to me. I'm so used to thinking of the tokenisation phase as a linear token stream that it never occurred to me to just count the function nesting directly to determine if the "async def" tokenisation rules are in effect - it's a very n

[issue24619] async/await parser issues

Yury Selivanov added the comment: An updated patch is attached. I had to implement a little bit more sophisticated tracking of one-line functions to fix parsing of things like def foo(): async def f(): pass async def f(): pass async = 1 I hope that test_coroutine.p

[issue24619] async/await parser issues

Martin Panter added the comment: Good news :) I guess this means we can also remove the sentence I added at . -- nosy: +vadmium ___ Python tracker

[issue24619] async/await parser issues

Guido van Rossum added the comment: Haven't reviewed the patch, but this approach sounds great (in fact I had assumed you were doing this already, and I was a bit surprised by some of the problems you encountered :-). -- ___ Python tracker

[issue24619] async/await parser issues

Yury Selivanov added the comment: 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

[issue24619] async/await parser issues

New submission from Stefan Krah: If I understand the reference manual correctly, these should probably be rejected by the compiler: >>> async def f(): ... def g(): pass ... async = 10 ... >>> async def f(): ... def async(): ... pass ... >>> async def f(): async = 10 ... >>