Reviving an old thread...

I just watched the video of Dino's talk at PyCon 2013 [1] and I am 
interested in updating their example code to run with asyncio 3.4 instead 
of tulip. I am writing to ask if anyone has done further work on this since 
may/2014 when Guido last wrote about it.

[1] http://lanyrd.com/2013/pycon/scdywd/

I believe their implementation of (a very small subset) of the asyncio 
event loop API on top of Tk is a great didactic example for understanding 
futures, the core of an event loop and the use of yield from for saner 
event oriented programming. As a teacher, I also think a GUI makes it 
easier to demonstrate a lot of the ideas in asyncio.

So if anyone has worked on this recently, or has any suggestions, any help 
will be most welcome!

I will report back as soon as I have something to show (or questions to 
ask).

Best,

Luciano


On Saturday, May 17, 2014 at 9:10:01 PM UTC-3, Guido van Rossum wrote:
>
> OK, I suppose you already figured this out, but the copied-and-pasted code 
> has some bugs due to renames. Attached is a fix that makes the program 
> actually work (if you can apply it that might save the next person who 
> looks at that code a few minutes of debugging).
>
> I noticed that on OSX I sometimes have to wiggle the mouse a bit so that 
> events happen. I think this is an OSX-specific problem with communication 
> between threads; I once figured this out with the help of the 
> tkinter-discuss list (chiefly 
> https://mail.python.org/pipermail/tkinter-discuss/2013-November/003520.html) 
> -- the only thing that reliably passes events between threads is 
> event_generate().
>
> Regardless, this would still not be a real solution, due to the copy-paste 
> nature of Dino's code. I expect that your proposal to run the IO loop in a 
> second thread makes the most sense, but I also suspect that that would take 
> away some of the (relative) elegance of using asyncio in the first place. 
> Also, 
>
> Let me play with these ideas some more. It would be a neat demo if it 
> worked.
>
> --Guido
>
>
> On Sat, May 17, 2014 at 4:40 PM, Guido van Rossum <[email protected] 
> <javascript:>> wrote:
>
>> I take back my speculation from last night; Dino's code did once work, 
>> and it uses yield from. I found the version Dino emailed me privately, 
>> cleaned up the tulip references, added the lambda helper you suggested, and 
>> then it worked. That version is definitely related to the one you checked 
>> in, but also pretty different; I will try to understand the differences and 
>> maybe I can help you. (You also need a Holmes.txt file; this one seems to 
>> work: http://www.gutenberg.org/cache/epub/1661/pg1661.txt.)
>>
>>
>> On Fri, May 16, 2014 at 9:40 PM, Guido van Rossum <[email protected] 
>> <javascript:>> wrote:
>>
>>> I suspect it never worked, or only with a private variant of Tulip 
>>> developed by Dino and Steve Dower, a long time ago, when Steve was arguing 
>>> for yield instead of yield-from. I believe I have a version in a private 
>>> scratch directory too somewhere. it would be good to revive this for real, 
>>> but It would probably be a pretty big project, and Dino's code would at 
>>> best be useful to glean some tricks from...
>>>
>>>
>>> On Friday, May 16, 2014, Victor Stinner <[email protected] 
>>> <javascript:>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Ádám Szieberth contacted me privately to notify me that
>>>> "asyncio_tkinter" does not work. I host this project in this
>>>> repository:
>>>> https://bitbucket.org/haypo/asyncio_staging
>>>>
>>>> The code was written by Dino Viehland for a talk, I just updated the
>>>> code for the new asyncio API (ex: import tulip => import asyncio).
>>>>
>>>> Is there anyone interested to fix the code?
>>>>
>>>> Adam wrote that the following line in tkapp.py :
>>>>    self.button["command"] = self.do_count
>>>>
>>>> must be replaced with:
>>>>    self.button["command"] = lambda: asyncio.Task(self.do_count())
>>>> or
>>>>    self.button["command"] = functools.partial(asyncio.Task, 
>>>> self.do_count())
>>>>
>>>> But it's not enough.
>>>>
>>>> guievents.py contains a class which inherits from AbstractEventLoop
>>>> and I see a lot of private code copied from asyncio, like
>>>> run_in_executor(). This code uses privates classes like Handle,
>>>> whereas Handle API has changed.
>>>>
>>>> I'm not sure that I understood the design. asyncio event loop and Tk
>>>> main loop are both running in the same thread? The code uses at least
>>>> two pools of threads.
>>>>
>>>> It looks like the Tk loop must run in the main loop. Why not using a
>>>> standard asyncio event loop in a dedicated thread with
>>>> call_soon_threadsafe()?
>>>>
>>>> Victor
>>>>
>>>
>>>
>>> -- 
>>> --Guido van Rossum (on iPad)
>>>
>>
>>
>>
>> -- 
>> --Guido van Rossum (python.org/~guido) 
>>
>
>
>
> -- 
> --Guido van Rossum (python.org/~guido) 
>

Reply via email to