> John Camera writes: > > It sounds like he feels Queue should just be part of threading but queues > > can be used in other contexts besides threading. So having separate > > modules is a good thing. > > Michael Chermside > Perhaps I am wrong here, but the Queue.Queue class is designed specifically > for synchronization, and I have always been under the impression that > it was probably NOT the best tool for normal queues that have nothing > to do with threading. Why incur the overhead of synchronization locks > when you don't intend to use them. I would advise against using Queue.Queue > in any context besides threading. I haven't used the Queue class before as I normally use a list for a queue. I just assumed a Queue was just a queue that was perhaps optimized for performance. I guess I would have expected the Queue class as defined in the standard library to have a different name if it wasn't just a queue. Well I should have known better than to make assumption on this list. :) I now see where Greg is coming from but I'm still not comfortable having it in the threading module. To me threads and queues are two different beasts. John M. Camara
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4