Ben Bass <benpaulb...@googlemail.com> added the comment: 'connectionless' is from how I see it as an analogy with UDP (vs TCP); why not just use a deque is primarily about having the same API - a client (getter) of the queue shouldn't know or care whether it is a 'lossy' queue or a normal queue. I guess most uses of a normal queue (excepting the 'task' functions) could just use a deque, but it wouldn't feel natural.
Use cases: non-critical event/status reporting is my canonical example. Specific examples: - a program which executes a long running process in a thread. It wants to update a GUI progress bar or similar, which must occur in a different thread because of the GUI model. By using a LossyQueue, the server thread is simplified; it doesn't have to care whether anything is listening on the other end, allowing greater decoupling (e.g. no changes required if there isn't a GUI). LossyQueues become part of the interface which can be used or not as required. - emulating/providing wrapper around UDP sockets - many application protocols support a get/set/report type interface with the addition of asynchronous events (e.g. SNMP, Netconf, SCPI). In these type of applications a suitable abstraction might be a normal Queue(s) for the standard commands and a LossyQueue for the events (which some applications might not care about). The point is that to the user of this abstraction, these two interfaces look the same. The 'server' doesn't care if a client is listening or not (it won't block and it won't use unlimited memory) The 'client' (if it wants to use it) doesn't know that it isn't a normal queue (same API). -> decouples server and client tasks. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7337> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
