I see. This could be an issue with anything that's an UI event loop. However, I would assume that in most cases you would take the existing UI framework's event loop and wrap an asyncio-compatible interface around it, rather than taking asyncio's event loop and augmenting it to support the UI. (Most UI frameworks are way too complex to replicate, so realistically you have no choice.)
It sounds as if things are different for curses, which doesn't really have its own event loop IIRC. (But does Urwid? I know nothing about it.) Anyway, I don't want to promise I'll accept a contribution, but I don't want to reject it unseen either -- can you come up with a minimal set of changes to asyncio that would implement the feature you desire? Maybe we can discuss such a patch more easily than I can understand your Urwid pull request. On Thu, Feb 27, 2014 at 11:31 AM, Kelketek Rritaa <[email protected]>wrote: > Urwid uses it to refresh the screen. Since curses lets changes build up > until you explicitly call refresh, it's efficient to do it after all other > calls in the loop. But you don't want to call it after every other single > action, and you don't want to call it just every 1/xth of a second, because > it might not always be needed. > > However, if something is changing in an Urwid program, and that causes an > AsyncIO task, chances are the screen needs to be refreshed. So making sure > that the screen always refreshes when there's a task seems like the right > way to do it. > > The same principle could be applied to anything with a buffer that needs > to be periodically flushed, but should be flushed at a fixed interval, and > not flushed at the end of every single task if there's going to be a batch > of them in one iteration of the loop. > > On Feb 27, 2014, at 1:12 PM, Guido van Rossum <[email protected]> wrote: > > (Redirecting the discussion back to the list.) > > > On Thu, Feb 27, 2014 at 10:46 AM, Kelketek Rritaa <[email protected]>wrote: > >> [...] >> But yes. I should certainly give examples on when it might be useful. >> >> Say you're working with another library. You might know that the library >> occasionally does something that changes state, but you either don't trust >> that library's code to make that change easily accessed by an AsyncIO task, >> or you just find it easier to read and maintain to add an idle task that >> occasionally cleans things up or updates things according to that other >> library's work. >> >> Alternatively, you might just have cleanup tasks that need to do x, y, >> and z, and adding an extra call to the end of every task to run the cleanup >> routine would result in repeated code that could just be taken care of at >> the end of the loop. >> > > Hm... Do you have specific examples of these? In either case it would seem > likely that the idle task could do a lot of extra work -- it will run > whenever the loop is about to go idle, whether or not there is anything to > clean up or update. > > -- > --Guido van Rossum (python.org/~guido) > > > -- --Guido van Rossum (python.org/~guido)
