[Python-3000] Useless methods in Queue module

Jeffrey Yasskin jyasskin at gmail.com
Tue Jan 15 02:49:26 CET 2008

On Jan 14, 2008 2:55 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
> On 14-Jan-08, at 1:32 PM, Charles Merriam wrote:
> > Not to be pedantic, but the major concern others are voicing is that
> > is that queue size is not reliable and is therefore a potential source
> > of hard to find threading bugs by naive users.   Why not just rename
> > q.size() to the unweildy name of q.est_size()?
> This is a misleading name.  The number returned from qsize() [not size
> ()] is perfectly reliable, in the sense that it is the exact size of
> the queue at some instant in time.

No, you're wrong. In CPython's implementation, it's likely that qsize
is implemented by locking the structure and reading a size field, but
there are other, more highly concurrent implementations, like Java's
[1], that have to traverse the structure to read its size.  Then the
returned value can be higher than the number ever "simultaneously"
contained in the queue, if some were added and some were removed
during the traversal.

Furthermore, it's misleading to think of even a locked
implementation's result as reliable. Ignoring problems with
simultaneity in the presence of threads, the "true" value could easily
have changed by the time qsize returns. And if it returns a value
that's not accurate, that can hardly be described as reliable. It
really is returning an estimate of the size, suitable only for use in
performance optimizations where you're prepared to handle it sometimes
being wildly wrong.

That said, I'm +1 on the current decision to keep it around, with its
current name. Users already have to look it up (since it's not spelled
len(q)), so they'll hit the warning.

[1]: ConcurrentLinkedQueue can't actually implement Queue in its
current form because it can't block. Something more like the data
structures described at
looks like it could, but I haven't examined the implementation well
enough to be sure. Nevertheless, it would be a bad idea to assume such
data structures will never be designed.

Jeffrey Yasskin

More information about the Python-3000 mailing list