Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
I no longer think this should be done. For most applications, cancel() speed is the least important task and isn't worth adding any extra baggage to the run() loop. The current cancel() code is only slow if the length is somewhat large (atypical for a scheduling app). Also, to my eyes the patch more than doubles the complexity of the module (which can currently be almost completely understood by examining the short run-loop). Lastly, a lazy cancel() keeps the references around longer (which may be undesirable for some apps). If you really think this module needs a lazy cancel(), then press ahead. Otherwise, we have no evidence that this a problem in the real world. The current cancel call is O(n) but runs at C speed which should be plenty fast enough for most cases. ---------- assignee: rhettinger -> serhiy.storchaka versions: +Python 3.9 -Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue13451> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
