Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
One of the provided links is duplicate (repost from StackOverflow). None of the links offer use cases which can be used to inform the design (i.e. is this the correct approach, should a timeout raise a RuntimeError like Condition.wait() does, should a timeout set a variable to indicate the timeout thread.join() does, should it just return with no indication of the reason for returning, should we just document the unfinished_tasks variable as read-only so that users can check it periodically, what are the common calling patterns, how does this fit in with the original design intent of letting worker threads finish all pending tasks before moving on to code that assumes that the work is done). Without motivating use cases, it is hard to create a correct design or to know whether this should be done at all. Unlike, thread.join() which has a long history in many contexts, the Queue.join/task_done API is newer; accordingly, the API should be grown somewhat cautiously. I don't think we've established using queue.join() with a time-out is a best practice or preferred pattern to solving a given problem. Instead, all we have is "it seems like a nice feature" which falls short of our usual standards. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9634> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
