Queue question

[Tim Peters]

[Alex Martelli]
> ...
> not_empty and not_full are not methods but rather instances of the
> threading.Condition class, which gets waited on and notified
> appropriately.  I'm not entirely sure exactly WHAT one is supposed to do
> with the Condition instances in question (I'm sure there is some design
> intent there, because their names indicate they're public); presumably,
> like for the Lock instance named 'mutex', they can be used in subclasses
> that do particularly fiendish things... but I keep planning not to cover
> them in the 2nd edition of the Nutshell (though there I _will_ cover the
> idea of subclassing Queue to implement queueing disciplines other than
> FIFO without needing to worry about synchronization, which I had skipped
> in the 1st edition).

Last time it was rewritten, I put as much thought into the names of
Queue instance variables as Guido put into them originally:  none. 
They have always "looked like" public names, but I'm at a loss to
think of anythng sane a Queue client or extender could do with them. 
Of course that's why the docs don't mention them.  I suppose an
extender could make good use of `mutex` if they wanted to add an
entirely new method, say:

    def get_and_put_nowait(self, new_item) :
        """Pop existing item, and push new item, atomically [blah blah blah]."""

I don't know of anyone who has done so, though.  I kept the name
`mutex` intact during the last rewrite, but didn't hesitate to get rid
of the former `esema` and `fsema` attributes.  Since no complaints
resulted, it's a pretty safe bet nobody was mucking with esema or
fsema before.