When would you pick queue.SimpleQueue, LifoQueue or PriorityQueue over a plain queue.Queue?

## One family and one outlier The `queue` module ships four classes. Three of them — `Queue`, `LifoQueue` and `PriorityQueue` — are the same machinery with a different ordering discipline: `LifoQueue` and `PriorityQueue` subclass `Queue` and override only the small hooks that decide how an item is stored and which one comes out next. Everything else is identical, including `maxsize`, the blocking and timeout behaviour of `put()`/`get()`, the `task_done()`/`join()` counter, and `shutdown()`. `SimpleQueue` is not part of that family; it is a deliberately smaller thing. ## LifoQueue: newest first `queue.LifoQueue` serves the most recently put item, so it behaves as a thread-safe stack. It suits work where recency dominates — a depth-first traversal frontier, or a retry buffer where the freshest attempt is the one worth making. Note the fairness cost: under sustained load the items at the bottom may never be served at all, which is fine for a search frontier and unacceptable for user work. ## PriorityQueue: lowest comparison wins `queue.PriorityQueue` keeps its contents as a binary heap and `get()` returns the smallest entry by ordinary Python comparison. Lowest first — a common slip is assuming the highest priority number wins; if you want that, negate the number. The interesting failure is ties. Entries are conventionally `(priority, payload)` tuples, and tuple comparison only looks at the second element when the first elements are equal. Put two entries with the same priority and a payload that does not define an ordering — a dict, or an instance of an ordinary class — and the heap raises `TypeError: '<' not supported between instances of ...`, from inside `put()`, on an input that worked fine yesterday. There are two standard fixes. Insert a monotonically increasing counter as a middle element, `(priority, next(counter), payload)`, which both guarantees comparability and makes ordering stable for equal priorities in insertion order — a heap is not stable on its own. Or use a dataclass declared with `order=True` and mark the payload field `compare=False` so it is excluded from comparison. Note also that the heap only orders the entry at the head correctly; iterating the internal list is not a sorted view. ## SimpleQueue: less is the feature `queue.SimpleQueue` is an unbounded FIFO with a deliberately minimal surface: `put`, `get`, `put_nowait`, `get_nowait`, `empty`, `qsize`. There is no `maxsize`, no `task_done()`, no `join()`, and as of 3.14 no `shutdown()` either. It accepts `block` and `timeout` on `put()` purely for signature compatibility and ignores them, because an unbounded queue can always accept an item. Two things justify choosing it. First, it is implemented in C and does less bookkeeping, so it is measurably faster on a hot path. Second, and more importantly, `put()` never blocks and never needs to acquire a Python-level lock that a reentrant call might already hold. That makes it safe to call from contexts where an ordinary `Queue.put()` is not obviously safe — a `__del__` method or a signal handler, both of which can run in the middle of arbitrary other code on the same thread. The classic use is a logging or event sink that must accept an item from anywhere without any possibility of deadlocking or waiting. The cost is everything it lacks. No `maxsize` means no backpressure — a `SimpleQueue` can grow without bound exactly like an unbounded `Queue`. No `task_done()`/`join()` means no completion barrier, so a coordinator has to count finished work itself. If you need either of those, pick `Queue`. ## What the subclasses inherit Because `LifoQueue` and `PriorityQueue` are ordinary subclasses of `queue.Queue`, everything the parent gained they gained too. `maxsize` bounds all three identically, so a priority queue can apply backpressure just as a FIFO one does. `queue.Full` and `queue.Empty` are raised by the same code paths. The `task_done()`/`join()` counter is inherited unchanged, and so is `shutdown()`, added in 3.13 — calling it on a `PriorityQueue` makes blocked `get()` and `put()` calls raise `queue.ShutDown` exactly as on the base class. That uniformity is why swapping a `Queue` for a `LifoQueue` in an existing pipeline is a one-line change: nothing else about the contract moves. `SimpleQueue` breaks that symmetry, and it is worth being precise about the version story. `shutdown()` arrived on `Queue` in 3.13; on 3.14 `queue.SimpleQueue` still has no `shutdown()` method at all, so a `SimpleQueue` consumer cannot be woken with `queue.ShutDown` and needs a sentinel item or a timed `get()` against a stop flag instead. Assuming the whole module gained `shutdown()` together is an easy and wrong inference. ## Choosing Start with `queue.Queue` and a `maxsize`; it is the right answer for ordinary producer-consumer work between threads. Reach for `LifoQueue` when recency beats fairness, for `PriorityQueue` when some items genuinely must jump the line and you have thought about ties, and for `SimpleQueue` when the producer side must never block or must be callable from a finalizer or signal handler.