Let's turn around the burden of proof :-) Rather than asking why Tulip doesn't have it (*), can you explain what use case does the "idle task" solve that can't be solved in some other way in Tulip already?
(*) Questions of the form "why doesn't Python have X" often feel rude -- a bit ike "when will you stop beating your wife"... On Thu, Feb 27, 2014 at 10:15 AM, Kelketek Rritaa <[email protected]>wrote: > Hello, all! > > While I was working on a method of adding Tulip to Urwid (a curses library > that allows your choice of event loops), I ran across an interesting > implementation detail that I found myself overwriting _run_once to solve. > > Some event loops (Such as Glib and Tornado) have a concept of 'idle > tasks'-- tasks which are run after the other tasks in the loop have already > been run (if there were no tasks run this time around, the idle tasks are > skipped). It doesn't appear that Tulip has a facility for this. Is there a > particular reason why it doesn't? I'd be happy to contribute some source > code that would allow it to, if there's interest in adding this feature. > > For some idea what I mean, you can take a look at the pull request I sent > to Urwid here: https://github.com/wardi/urwid/pull/57/files (source issue > request here: https://github.com/wardi/urwid/pull/57/) > > A couple notes about these changes: The ones in this particular diff are > intended to interrupt the loop for Urwid's workflow, I wouldn't do it for > the official library that way, instead being sure to use > call_exception_handler and whatnot, and wrap the tasks in proper Task > objects rather than just passing the functions around. > > Would this be welcome? Is this concept in general defective, and should it > yield to a more right way to do it? > -- --Guido van Rossum (python.org/~guido)
