-1 if I may.
I use qsize() to sustain an average queue size (unreliably) but not
allowing the queue to be full. Certainly, this could be done in some
other way, but the existence of the method remains very useful.
cheers
On Jan 11, 2008, at 8:13 PM, Raymond Hettinger wrote:
I proposed to
On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the n
How about dropping empty() and full(), but keeping qsize()? empty() is
trivially rephrased as qsize()==0; I haven't heard any use cases for
full().
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-300
On Jan 14, 2008 5:48 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs.python.org/issue1682)
On Jan 14, 2008 1:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> How about dropping empty() and full(), but keeping qsize()? empty() is
> trivially rephrased as qsize()==0; I haven't heard any use cases for
> full().
I think the point is that, with multiple threads, those methods are
not gua
On Jan 14, 2008 2:15 PM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 1:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > How about dropping empty() and full(), but keeping qsize()? empty() is
> > trivially rephrased as qsize()==0; I haven't heard any use cases for
> > full().
>
> I
On Jan 14, 2008 11:15 AM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 1:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > How about dropping empty() and full(), but keeping qsize()? empty() is
> > trivially rephrased as qsize()==0; I haven't heard any use cases for
> > full().
>
>
> I'm not sure people who ignore the big "Because of
> multithreading semantics, this is not reliable" warnings
> should be catered to. Since others have contributed use-cases
> for qsize()'s advisory information, it should probably stay around.
I concur.
I do recommend we dump q.empty() and q.
Sounds like we have all-round agreement. Go for it.
On Jan 14, 2008 11:55 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I'm not sure people who ignore the big "Because of
> > multithreading semantics, this is not reliable" warnings
> > should be catered to. Since others have contributed use
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()?
On Jan 14, 2008 11:59 AM, Guido van Rossu
Leif> I think the point is that, with multiple threads, those methods
Leif> are not guaranteed to be correct, whereas trapping the exceptions
Leif> apparently are, and therefore, leaving those methods in is
Leif> confusing to new programmers who might assume they work and use
L
On Jan 14, 2008 4:54 PM, <[EMAIL PROTECTED]> wrote:
> For the guy who said he wanted to maintain an average qsize (not too small,
> not too big), empty() and full() don't help. He'll have to implement a
> qsize() function or monkey patch (or subclass) the Queue class. I agree
> with Guido that e
On Jan 14, 2008 1:54 PM, <[EMAIL PROTECTED]> wrote:
>
> Leif> I think the point is that, with multiple threads, those methods
> Leif> are not guaranteed to be correct, whereas trapping the exceptions
> Leif> apparently are, and therefore, leaving those methods in is
> Leif> confusi
[Skip]
> if not q.qsize():
>print q.qsize()
> might print something besides 0. And if it is a surprise,
> they should probably not be programming with threads.
> 0.5-even-rounded wink>
I concur. Let's leave qsize() alone. Even renaming it would cause unnecessary
breakage.
FWIW, th
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
Oh, you are right. I thought that save_inst() used inst_persistent_id,
but that isn't the case. Now, I have checked more thoroughly and found
the relevant piece of code:
if (!pers_save && self->inst_pers_func) {
if ((tmp = save_pers(self, args, self->inst_pers_func)) != 0)
On Jan 14, 2008 2:55 PM, Mike Klaas <[EMAIL PROTECTED]> 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
On 14-Jan-08, at 5:49 PM, Jeffrey Yasskin wrote:
> On Jan 14, 2008 2:55 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
>> 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
Mike> The real concern is that qsize() > 0 doesn't guarantee that a
Mike> subsequent .get() will not block, nor that qsize() < maxsize
Mike> guarantee that .put() will not block. Incidentally, I find this
Mike> warning much less confusion than the vague "Because of
Mike> multi
>> 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.
As Mike explains: he is right, you are wrong.
> In CPython's implementation, it's likely t
On Jan 14, 2008 6:31 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 14-Jan-08, at 5:49 PM, Jeffrey Yasskin wrote:
>
> > On Jan 14, 2008 2:55 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
>
> >> This is a misleading name. The number returned from qsize() [not
> >> size
> >> ()] is perfectly reliable, i
21 matches
Mail list logo
