[issue22412] Towards an asyncio-enabled command line

Matthias Bussonnier added the comment: I believe https://bugs.python.org/issue34616 is related as it track async-exec and seem to have a couple of devs that are favorable to it. -- nosy: +mbussonn ___ Python tracker

[issue22412] Towards an asyncio-enabled command line

Change by pmpp : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22412] Towards an asyncio-enabled command line

Martin Teichmann added the comment: well, I beg to differ. Again, to your points: to a) You claim that my flag would have to be supported by every python platform. Well, the very same built-in function has another flag, PyCF_ONLY_AST, whose precise meaning, according to the docs, might change

[issue22412] Towards an asyncio-enabled command line

Guido van Rossum added the comment: There's a sage piece of advice somewhere in the developer docs. Know when to give up. I think you need to write a PEP trying to argue that supporting yield from in the REPL is essential to a large category of users, so you can lobby for support. In the

[issue22412] Towards an asyncio-enabled command line

Martin Teichmann added the comment: Well, so I am giving up, apparenty my work is not wanted here. But not before submitting at least the last version of my patch. I seperated out my _input function into two, start_input and continue_input, which are supposed to work in a loop as in

[issue22412] Towards an asyncio-enabled command line

Martin Teichmann added the comment: And as a last comment, just for completeness, a complete async console. With it you can do cool things like from asyncio import sleep, async def f(): ...yield from sleep(3) ...print(done) yield from f() [after 3 seconds] done async(f()) [wait

[issue22412] Towards an asyncio-enabled command line

Guido van Rossum added the comment: I'm sorry you feel that way. I hope one day you will understand the other side of this kind of issue. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org

[issue22412] Towards an asyncio-enabled command line

Martin Teichmann added the comment: Hi Guido, thanks for the quick response, so my response to your post: to 1: thanks! to 2: I am trying to put most of the stuff into a 3rd party module, unfortunately I need changes in the python compiler, and given that monkey patching is not so simple in

[issue22412] Towards an asyncio-enabled command line

Martin Teichmann added the comment: As promised, a new patch now for the current head. Last time I apparently got confused with how hg works, sorry. -- Added file: http://bugs.python.org/file36623/patch2 ___ Python tracker rep...@bugs.python.org

[issue22412] Towards an asyncio-enabled command line

Guido van Rossum added the comment: OK. Trying to understand the patch, there seem to be three parts to it: (a) Changes to CPython to add a new flag to the exec/eval flags argument that sets the GENERATOR flag in the resulting code object. This seems the most fundamental, but it also feels

[issue22412] Towards an asyncio-enabled command line

New submission from Martin Teichmann: This patch is supposed to facilitate using the asyncio package on the command line. It contains two things: First, a coroutine version of builtin.input, so that it can be called while a asyncio event loop is running. Secondly, it adds a new flag to

[issue22412] Towards an asyncio-enabled command line

Guido van Rossum added the comment: 1. Great that you're trying to implement this! 2. But I really recommend that you try to structure this as a 3rd party module first rather than patching the Python distribution -- it's much harder to get accepted. Or as a pure-Python patch to asyncio,