title: Why does Python's queue.Queue.get() permit returning early from timeouts?
body: <p>UPDATE: This question is based on a faulty mental model of how Queue.get() was actually behaving, which was caused by some slightly ambiguous documentation but mainly by a buggy, hand-rolled implementation of <code>timedelta.total_seconds()</code>. I discovered this bug when trying to prove that the original answers where incorrect. Now that <code>timedelta.total_seconds()</code> is provided by Python (since 2.7), I will move to use that.</p>
  
  <p>Sorry for the confusion.</p>
  
  <hr/>
  
  <p>This isn't a "Why does my code not run?" question, but a "What is the motivation behind this design decision?"</p>
  
  <p>Since 2.3, Python's queue module contains a Queue class with a get method, that takes a timeout parameter. Here's the section from the manual:</p>
  
  <blockquote><code>Queue.get([block[, timeout]])</code><br/>
  Remove and return an item from the queue. If optional args block is true and timeout is None (the default), block if necessary until an item is available. If timeout is a positive number, it blocks <em><strong>at most</strong></em> timeout seconds and raises the Empty exception if no item was available within that time. [...]
  </blockquote>
  
  <p>(Emphasis mine)</p>
  
  <p>Note that it may raise an Empty exception <em>even if it hasn't reached the timeout</em>. In fact, I am seeing that behaviour on Ubuntu (but not Windows). It is bailing just a little early and it has had minor consequences on my code - I can code around it though.</p>
  
  <p>Most blocking timeouts take a <em>minimum</em> timeout, which makes sense on a non-real-time OS, including Windows and Linux. There is no guarantee that the OS will context switch to your process or thread by any given deadline.</p>
  
  <p>However, this one takes a <em>maximum</em> timeout. Can anyone explain how this design decision might make sense?</p>