For this you should probably use an integration of asyncio (which can do
async subprocess output nicely) with Tkinter. Over in tulip-land there is
an demo of such an integration.
On Tue, May 5, 2015 at 6:03 PM, Terry Reedy
On 5/5/2015 6:25 PM, Yury Selivanov wrote:
Yes, there is no other popular event loop for 3.4 other
than asyncio,
There is the tk(inter) event loop which also ships with CPython, and which is commonly used.
that uses coroutines based on generators
Oh ;-) Tkinter event loop is callback based. AFAIK, so is the asyncio event loop, but that is somehow masked by tasks that interface to coroutines. Do you think the 'somehow' could be adapted to work with the tkinter loop?
What I do not understand is how io events become event loop Event instances. For tk, keyboard and mouse actions seen by the OS become tk Events associated with a widget. Some widgets generate events. User code can also generate (pseudo)events.
My specific use case is to be able to run a program in a separate process, but display the output in the gui process -- something like this (in Idle, for instance). (Apologies if this misuses the new keywords.)
async def menu_handler() ow = OutputWindow(args) # tk Widget proc = subprocess.Popen (or multiprocessing equivalent) out = (stdout from process) await for line in out: ow.write(line) finish()
I want the handler to not block event processing, and disappear after finishing. Might 492 make this possible someday? Or would having 'line in pipe' or just 'data in pipe' translated to a tk event likely require a patch to tk?
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)