[issue34616] implement "Async exec"

miss-islington added the comment: New changeset 2ddbd21aec7f0e2f237a1073d3e0b313e673413f by Miss Islington (bot) (Matthias Bussonnier) in branch 'master': bpo-34616: Document top level async in whatsnew/3.8. (GH-13484)

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > section to document the new flag inside "Improved Modules" category Done in https://github.com/python/cpython/pull/13484 -- ___ Python tracker

[issue34616] implement "Async exec"

Change by Matthias Bussonnier : -- pull_requests: +13396 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Maybe you used "git merge" and your PR "contained" changes from other issues? I quasi-nerver merge, either `rebase interactive` or `reset --hard HEAD`... I even proscribed "git pull" from my CLI.. but you know everybody does mistakes. > Would be

[issue34616] implement "Async exec"

STINNER Victor added the comment: > And I'm guessing you will collect what's in NEWS.d ? Otherwise I'm happy to > contribute some text. let me know the best way. One option to document it is to add a new "builtins" section to document the new flag inside "Improved Modules" category:

[issue34616] implement "Async exec"

Yury Selivanov added the comment: > And I'm guessing you will collect what's in NEWS.d ? Otherwise I'm happy to > contribute some text. let me know the best way. Would be great if you could make a PR to add an entry to whatsnew/3.8.rst (as Victor suggests) --

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Yes, Elvis and I will take care of that later. And I'm guessing you will collect what's in NEWS.d ? Otherwise I'm happy to contribute some text. let me know the best way. -- ___ Python tracker

[issue34616] implement "Async exec"

STINNER Victor added the comment: > Could it be due to rebasing and force-pushing ? Cause I did force-push on > this branch a couple of times... Maybe you used "git merge" and your PR "contained" changes from other issues? -- ___ Python tracker

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Any idea why PR 13148 has been linked to unrelated bugs.python.org issues? Could it be due to rebasing and force-pushing ? Cause I did force-push on this branch a couple of times... -- ___ Python tracker

[issue34616] implement "Async exec"

STINNER Victor added the comment: > Yes, Elvis and I will take care of that later. Well, it would be nice to get a first mention before the next release, to see all new shiny Python 3.8 features ;-) The text can be reworded later if needed ;-) --

[issue34616] implement "Async exec"

STINNER Victor added the comment: Any idea why PR 13148 has been linked to unrelated bugs.python.org issues? I saw 3 of them: bpo-35363, bpo-25234, bpo-33725. https://mail.python.org/pipermail/python-dev/2019-May/157592.html -- ___ Python tracker

[issue34616] implement "Async exec"

Yury Selivanov added the comment: > Would it be possible to document this change in What's New in Python 3.8? Yes, Elvis and I will take care of that later. -- ___ Python tracker

[issue34616] implement "Async exec"

STINNER Victor added the comment: Would it be possible to document this change in What's New in Python 3.8? -- nosy: +vstinner ___ Python tracker ___

[issue34616] implement "Async exec"

Ned Deily added the comment: New changeset eca18aac7b5952d23854d27dc8e502dfb0bb0505 by Ned Deily (Yury Selivanov) in branch 'master': bpo-34616: Fix code style and unbreak buildbots (GH-13473) https://github.com/python/cpython/commit/eca18aac7b5952d23854d27dc8e502dfb0bb0505 --

[issue34616] implement "Async exec"

Change by Yury Selivanov : -- pull_requests: +13385 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Andrew Svetlov added the comment: Great! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Change by Yury Selivanov : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue34616] implement "Async exec"

Yury Selivanov added the comment: New changeset 565b4f1ac7304d1e690c404ca8316f383ba60862 by Yury Selivanov (Matthias Bussonnier) in branch 'master': bpo-34616: Add PyCF_ALLOW_TOP_LEVEL_AWAIT to allow top-level await (GH-13148)

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > I'll be working on CPython on Friday. Will take a look at your PR first thing. Thanks, let me know if the is anything I can do for you in exchange; also thanks again for sitting with me and stepping me through the things at PyCon. --

[issue34616] implement "Async exec"

Yury Selivanov added the comment: I'll be working on CPython on Friday. Will take a look at your PR first thing. -- ___ Python tracker ___

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: I see the 3.8 feature freeze seem to be end of next-week; do you think that async-exec (gh-13148) has a chance of getting in ? I'm happy to do modification to the PR but would need some more reviews. I'm happy to take some other tasks of your plate is

[issue34616] implement "Async exec"

Andrew Svetlov added the comment: Matthias, please use GH-13148 for pointing on github pull requests. # is for links to this tracker issues. -- stage: patch review -> ___ Python tracker

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Thank Yuri for the guidance; I worked on it, cleaned things up a bit and posted a draft PR (#13148) with some example. That helps cleaning up a lot of code; and in the PR is a ~30 line example that implement an asyncio-repl. --

[issue34616] implement "Async exec"

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13063 stage: -> patch review ___ Python tracker ___ ___

[issue34616] implement "Async exec"

Yury Selivanov added the comment: Here's a VERY rough first implementation to play with: https://github.com/1st1/cpython/commit/ad2ed0aed922d7c36f2fced64264124613e37f09 -- ___ Python tracker

[issue34616] implement "Async exec"

Andrew Svetlov added the comment: Sorry, I don't know all the compilation workflow details to help you quickly (and will be very busy on other tasks during the sprint). Yuri will be absent on sprints. -- ___ Python tracker

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Did I miss something? No I think for the async stuff that should be a big improvement already. Either a flag, or different "MODE", like 'single','exec' and 'eval'. I'l love for something like 'exec' but where not only we can have multiple statement,

[issue34616] implement "Async exec"

Andrew Svetlov added the comment: I recall the idea of passing a specific flag to `compile()` for accepting await and family on top level of passed code string. Than compile can return a code object with CO_COROUTINE flag set. Returned code object can be analyzed for this flag and executed

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Extra notes from in-person discussion; We might want a both a Sync-REPL and Async-REPL `compile()` mode depending on wether the REPL support async. One of the other question was wether `exec` should look at wether an eventloop is running, or if it

[issue34616] implement "Async exec"

Yury Selivanov added the comment: > No, I do not have a patch. I can provide a few test case That would be helpful! > and I am happy to spend some task to sit-down and discuss what we exactly do > so far in IPython. I'm flying back Sunday morning. Yes, let's do that around Friday/Saturday

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > async-input isn't even useful for ipython, is it? you use prompt-toolkit :-) You don't have to use prompt_toolkit (https://github.com/ipython/rlipython), but yes we don't need this. > Do you have a patch for this? If not I can take a look at this

[issue34616] implement "Async exec"

Yury Selivanov added the comment: > Yeah, I think this is pretty simple: the runtime/stdlib should provide the > primitives to compile top-level async code, get coroutines, etc., and then a > REPL like ipython can take care of handing that off to asyncio or whatever > library they want.

[issue34616] implement "Async exec"

Nathaniel Smith added the comment: > My response was to not take care of that in the first time, but provide the > building blocks for alternative REPL, in a second time provide an > async-input, and a way to register runner for alternative async libraries. Yeah, I think this is pretty

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Slides and demo (videos) during PyCon2019 Language Summit: https://github.com/Carreau/talks/tree/master/2019-05-01-Language-Summit One question was how to handle non-asyncio in Core Python, REPL. My response was to not take care of that in the first

[issue34616] implement "Async exec"

Change by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Change by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Or actually there are two options to think about: you can submit a general > talk, or submit a talk to the language summit. (Or write two talks and do > both, I guess.) They're pretty different – the summit is a more informal > thing (no video,

[issue34616] implement "Async exec"

Nathaniel Smith added the comment: > I'm thinking of submitting a talk at PyCon to explain what we've discover so > far in IPython. You totally should! Or actually there are two options to think about: you can submit a general talk, or submit a talk to the language summit. (Or write two

[issue34616] implement "Async exec"

pmpp added the comment: i already use prompt_toolkit on droid as it uses concurrent futures for completion and threads are allowed on that platform, and yeah it is quite good. but no way to use it on emscripten where cpython is 100% async ( it uses dummy_threading to load asyncio ). best

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: In IPython we use `prompt_toolkit` which does already provide a async readline alternative. Also have a look at https://github.com/ipython/ipython/blob/320d21bf56804541b27deb488871e488eb96929f/IPython/core/interactiveshell.py#L121-L150 Seem to be

[issue34616] implement "Async exec"

pmpp added the comment: indeed adding async flag to compile and providing some 'aexec' is a very good idea ! *an async repl is really usefull when stuck with a threadless python* ( specific engines, or emscripten cpython ) "top-level async is invalid syntax" : Rewinding the readline

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: So through time our heuristic to check wether a code should be async or not grew: https://github.com/ipython/ipython/blob/320d21bf56804541b27deb488871e488eb96929f/IPython/core/async_helpers.py#L94-L165 There also seem to be some code that uses

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > A utility to check whether an AST requires async mode should be fairly > straightforward. Here is one case we forgot in IPython apparently : In [1]: x = 1 ...: def f(): ...: nonlocal x ...: x = 1 This is not detected as a syntax

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > I think the first thing is to add async "modes" to compile: in particular > "async-exec" and "async-single". These would be like the current "exec" and > "single" modes respectively, except that they act like the code is inside an > "async def", so

[issue34616] implement "Async exec"

Nathaniel Smith added the comment: I think the first thing is to add async "modes" to compile: in particular "async-exec" and "async-single". These would be like the current "exec" and "single" modes respectively, except that they act like the code is inside an "async def", so "await" is

[issue34616] implement "Async exec"

Change by Matthias Bussonnier : -- nosy: +minrk, willingc, yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34616] implement "Async exec"

New submission from Matthias Bussonnier : Hi, This is an issue, prompted by twitter (https://twitter.com/Mbussonn/status/1038866329971961859) and by the imminent release of IPython 7.0 that provides an async REPL to discuss the introducion of something I'll call "Async exec", the exact