[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. -- http://mail.python.org/mailman/listinfo/python-list