Raymond Hettinger added the comment: > And even when Queue.unfinished gives wrong (outdated) information, > it can lead to creation one new thread that is not really required > at the moment. That is not a big mistake, I suppose (comparing to > creation all N threads during placing first N tasks in queue > without considering the volume of concurrent tasks).
IMO, this isn't worth expanding the Queue API. The thread pool concept explicitly allows up to poolsize threads and occasionally having one extra thread within the allowed poolsize isn't important. Also, it is unclear why a new thread is being launched if there in nothing in the work queue (unfinished tasks is only interesting when qsize==0). For other users, the new method is problematic because it is distracting and prone to misuse (potentially out-of-date upon return and potentially meaningless if task_done isn't being used). I believe the new method will cause more problems than it fixes. Also, I really don't like the mission creep. Queue objects are primarily about managing a queue of inputs. Monitoring and managing consumers is another (mostly orthogonal) realm. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29603> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
