Author stutzbach
Recipients akuchling, djarb, facundobatista, forest, giampaolo.rodola, gvanrossum, intgr, j1m, jafo, josiahcarlson, kevinwatters, markb, mcdonc, pitrou, r.david.murray, stutzbach, tseaver
Date 2010-04-30.14:49:43
SpamBayes Score 0.000429592
Marked as misclassified No
Message-id <1272638986.21.0.129713662644.issue1641@psf.upfronthosting.co.za>
In-reply-to
Content
I like the idea of leveraging the sched module.  It encapsulates the priority queue, allowing the user to be agnostic to the underlying data structure.  If someday we have a data structure in the collections module that provides an efficient delete-key operation, we can switch.  Giampaolo's patch forever ties us to heapq.

That said, I believe Josiah's patch could be simplified considerably.  Here are two ideas, which can be evaluated separately:

- The performance improvements to sched should be part of a separate patch and listed under a separate issue in the tracker.

- Let the user leverage the existing scheduler API.  Cut out scheduled_task and call_later, which just wraps the scheduler API.  The user can simply call scheduled_tasks.enter() or scheduled_tasks.cancel().  It's one less API for them to learn and one less for us to maintain.

Also, fix one small bug:

- Add a function to create a sched.scheduler().  Several functions take an optional "tasks" parameter, but there's no way to allocate a scheduler without peeking at the implementation and duplicating how it allocates the global one.
History
Date User Action Args
2010-04-30 14:49:46stutzbachsetrecipients: + stutzbach, gvanrossum, akuchling, facundobatista, jafo, josiahcarlson, tseaver, pitrou, forest, giampaolo.rodola, kevinwatters, djarb, markb, r.david.murray, intgr, mcdonc, j1m
2010-04-30 14:49:46stutzbachsetmessageid: <1272638986.21.0.129713662644.issue1641@psf.upfronthosting.co.za>
2010-04-30 14:49:45stutzbachlinkissue1641 messages
2010-04-30 14:49:43stutzbachcreate