Such a purely cosmetic API change would be too much churn given that we're getting ready for the Python 3.4 release.
On Thu, Feb 20, 2014 at 11:55 AM, Constantin Michael < [email protected]> wrote: > Apologies for resurrecting. > > Task.all_tasks() and Task.current_task() seem to me to group well with the > Task functions defined at module scope (documented in section 18.5.2.5). > The requirement of the event loop not knowing about tasks would be > maintained. > > Constantin > > > On Tuesday, 3 December 2013 17:49:42 UTC+2, Guido van Rossum wrote: > >> This is because the event loop has no knowledge about tasks. You should >> be able to use the event loop without knowing about tasks. You should also >> be able to *implement* an event loop (from scratch, not by subclassing >> BaseEventLoop) without knowing about tasks. So it felt wrong to >> artificially tie the two together and it felt natural to keep the >> administration in the Task class. (Of course, the Task implementation >> *does* know about event loops.) >> >> >> On Tue, Dec 3, 2013 at 5:53 AM, Victor Stinner <[email protected]>wrote: >> >>> Hi, >>> >>> I would like to know why a class method was chosen (Task.all_tasks()) >>> instead of a method on the event loop (BaseEventLoop.get_tasks())? >>> >>> Victor >>> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido)
