Queue.Queue(), accepts any value as the maxsize, example:

foo = Queue.Queue('j');
l = []; foo = Queue.Queue(l);
...

Shouldn't the value passed be checked on init :
isinstance(maxsize, int) ?

This is probably a matter of style.  For the most part, library code
avoids isinstance() checks and lets the errors surface downstream. 

If a check gets added, we should probably also check that the value is
non-negative.  The checks should not be backported because it could
break Queue subclasses that rely on being able to pass in a non-int
value (like None or like a dynamic object that allows the maxsize to be
increased during the run).

I'm unclear why this got classified as a security issue rather than just
an RFE for Py2.6.

Is there a problem with a dynamic object that changes the maxsize? I
think it might be better to ignore it, and let the client get exceptions
when their maxsize is compared.

Firts: the security type was my error.

The method wich uses the maxsize:
"""
# Check whether the queue is full
def _full(self):
  return self.maxsize > 0 and len(self.queue) == self.maxsize
"""

@rhettinger: As per the documentation, negative values result on an
infinite Queue; well that AND will never be fulfilled with a negative
value anyway;

@gutworth: What I mean is that's "awkward", if you put an string for
example, it'll be the size of the string wich will be used on the
__cmp__ and on len(), but that's not explicit, or is it?

Example:

[zan@tails ~]$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...   def __init__(self): pass;
...
>>> c = C()
>>> import Queue
>>> a = Queue.Queue(c)
>>> len(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: C instance has no attribute '__len__'
>>> a = Queue.Queue(c)
>>> a.put('q')
>>> a.get()
'q'
>>> a.put(1)
>>> a.put(2)
>>> a.put(3)
>>>

Rafael, I agree that it's awkward, and I'm not against restricting the
maxsize to just something sane. However, I'm worried this (Raymond's
patch) will be too restrictive by not allowing dynamic changing of
maxsize. (Of course, you could just change the maxsize attribute of the
Queue, but that would require holding the mutex, too.)

What about requiring maxsize to be convertible to an int?
This would allow dynamic objects, if they define an __int__ method.
I join a patch.

I like it.

@gutworth: Since one of the main uses of Queue is with threads, I think
it *really* should acquire the mutex before changing the maxsize;

@amaury.forgeotdarc: Your patch makes the point of allowing the size to
be changed at some other place (e.g.: an attribute of an instance passed
as the maxsize), but as stated above I think (am not an expert) the
mutex really should be held before the maxsize change, another point:
using an instance on your patch a call to Queue.maxsize would return
something like:
"""
Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...   def __init(self): self.n = 1;
...   def __int__(self): return int(self.n);
...
>>> c = C()
>>> import Queue
>>> q = Queue.Queue(c)
>>> q.maxsize
<__main__.C instance at 0xb7c341ac>
>>>                                        
"""
wich would force to have a get() to the maxsize attribute;

I have added a diff;

Mine patch doesn't address the "hold the mutex before changing the
maxsize" guess it would then force a get()?

It's probably best to close this as "won't fix".  Each of the patches 
limits the module or complicates it a bit.  I'm not sure there's even a 
real problem here.  My preference is to leave this code untouched.

Maybe, we should change change the constructor to use self.maxsize =
int(maxsize). Then we can provide a set_maxsize method that will acquire
the mutex and preform the change. This is will restrict the type of
maxsize and allow for easy dynamic changing.

Recommend closing this.  No need to muck-up a clean module to solve a 
non-problem.

Raymond, are you referring to the int checking, my new method, or both?

Both.  There is no issue here worth adding a new method.

Ok. I agree that we shouldn't muddy the waters of Queue by checking for
int. (set_maxsize would be unneeded) Go ahead and close.

For what it's worth, I do think this is an issue. As it currently
stands, not only does the module silently accept invalid values, but the
mutex issue exists (and is also silently ignored) if an object returning
dynamic values is passed as maxsize. IMHO, the waters are already muddy,
it's just that the mud is blue so everything seems alright :)

I think zanella's patch is the way to go, even if it requires adding a
setter method.

Many places in the stdlib accept values which are not valid. I believe
this is because the library trusts you to do the right thing in the name
of performance and cleaner, simpler code. IMO, adding a set_maxsize
method wouldn't be a sin, but Raymond (who is I'm sure wiser than me)
disagrees.

Just to exemplify:
"""
from threading import Thread
import time
import Queue

class C:
  def __int__(self):
    return 3
  
  #def __del__(self): print "collected..." # won't happen since q holds
a reference to it

c = C()
q = Queue.Queue(c)

# Not dynamic
print "maxsize: ", q.maxsize

# Not full() with instance
print c > 0
print len(q.queue) == q.maxsize

class T(Thread):
  def __init__(self, q):
    self._q = q
    Thread.__init__(self)
  
  def run(self):
    #For sme bizarre motive
    self._q.maxsize = 5

#Ends up being infinite most of the times
t = T(q)

for i in xrange(1000):
  q.put_nowait(i)
  if i == 1: # otherwise the "and len(self.queue) == self.maxsize" will fail
    t.start()
    time.sleep(1)

t.join()
"""

I guess rhettinger is right, there's no issue here, anyone that decides
to change the maxsize afterwards should know what is doing.

The only "possible" problem I'm able to see is someone passing an object
wich has __int__() and expecting it to be used.

> The only "possible" problem I'm able to see is someone passing an object
wich has __int__() and expecting it to be used.
They should be explicit and say Queue(int(object_with__int__)).