[issue22412] Towards an asyncio-enabled command line

[Martin Teichmann]

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 C, changing the compiler would
mean to re-write it, I know that has been done, but I figured that 
starting a project like PyPy or jython is a bit too much for me 
right now.

to 3: I started with the repo head of friday night... apparently
I was not fast enough to submit this patch before someone changes
the python code to the point that my patch doesn't apply anymore.
I'll try to fix that soon.

to 4: I'll write some docs.

to 5: well, there is a callback function just some lines up which
will call future.set_result(None). Maybe that was a bit too slick,
I'm open for comments on how to do that better.

to 6: the C code I put into readline.c is mostly a merge of
readline_until_enter_or_signal (in readline.c) and builtin_input
(in bltinmodule.c). You're definitely right that those functions
could do with some refactoring, but I didn't dare to since they
are full of complicated special code for special platforms, and
I have no chance to test the code on a machine which has a
completely outdated version of the readline library, so I picked
the code I needed.


to 6: I thought about writing the input part of my patch as a 3rd
party library, but then I saw the state of builtin.input and
thought that it would actually be a good idea to shine some light
onto the state of that function, it is actually a horrible mess.
Just look at all the awful dirty tricks that the people over at
IPython have to do to use it (im)properly (I'm talking about
IPython.lib.inputhook*).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22412>
_______________________________________