On Tue, Apr 29, 2008 at 5:01 AM, Thomas Wouters <[EMAIL PROTECTED]> wrote: ... > > > * sched > > > > > > + Replaced by threading.Timer. > > > > I don't see sched as obsoleted by threading.Timer. It's much simpler > > to use (no need for locking) and more efficient (no legions of > > sleeping threads). Instead, maybe it should be removed because it's > > trivial to reimplement as well as being overshadowed by all the other > > event loops built into bigger systems (tk, qt, gtk, twisted, etc)? > > More importantly, sched doesn't use threads, so replacing it with > threading.Timer is inappropriate :) But yes, it should just go.
Oops, sorry for the duplicate subthread -- I had mailed my objections to sched removal privately to Brett first (trying to avoid the thread explosion he feared) and I thought I had later mailed the whole list but hadn't, so I hit send again first thing this morning. Anyway, I disagree that sched should go away from the Python standard library. It's not trivial to reimplement it _properly_, it's a great way to code a pure-Python cron-substitute that works across all platforms including very limited (e.g. embedded) ones w/o threads and with scarce memory (without the overhead of the bigger systems, which may or may not be well supported on a given limited platform), AND it's an excellent way to do _simulations_ -- I use it regularly for both pure simulations AND for systems that, in production, run on a real timeline, and can also be easily "simulation-tested" by feeding sched with functions that read the simulated timeline (instead of time.time and time.sleep). Please let's keep it! Alex _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
