The example of AMQP is perhaps a stronger argument for why multiprocessing.Queue.close should (or does) exist, not as much a reason for queue.Queue.

The strongest point, I think, is the argument that existing patterns are lacking.

In the multiprocessing module, the pattern of placing None into a queue.Queue to communicate between threads is also used but with a slightly different use case:  a queue may have multiple None's added to it so that the queue's contents may be fully consumed and at the end the consumers understand to not look for more work when they each get a None.  It might be restated as "do your work, then close".  If close were introduced to queue.Queue as proposed, it would not eliminate the need for this pattern.

Thankfully inside multiprocessing the number of threads is known (for example, a thread to manage each process created by multiprocessing) making code possible such as:  `inqueue.queue.extend([None] * size)`.  In the more general case, the point that `size` is not always known is a valid one.  In this same vein, other parts of multiprocessing could potentially make use of queue.Queue.close but at least in multiprocessing's specific case I'm not sure I see a compelling simplification to warrant the change.  Though multiprocessing doesn't provide one, I think it would be helpful to see concrete use cases where there would be a clear benefit.