A very tiny patch which places a DeprecationWarning inside Queue.empty
and Queue.full

Add comment to NEWS as documented...

Can you make a single patch for Lib/queue.py and Misc/NEWS and remove
any uses of emtpy/full in the standard library including multiprocessing.

Also, for deprecations, it's always nice to have the message suggest an
alternative, something like:  "The empty() method is deprecated and
scheduled to be removed in Py3.2.  Instead, use qsize() or catch a
queue.Empty exception."

Unit tests are a great thing as well.  Also, the deprecation warnings
you've added are the really annoying kind.  They refer to users to the
source of the deprecated methods themselves!  A vastly preferable use of
the warnings system is to refer users to the *callers* of the deprecated
methods.  Try passing different values for the stacklevel parameter of
the warnings.warn function until you get a warning that is more helpful.

Patch covering all files in a single patch.
  * Updated warning message
  * Updated multiprocessing tests to avoid calls to empty and full
  * Placed deprecation warning in multiprocessing methods
  * Update wsgui to avoid deprecated calls

Issues:
  * Noticed no warnings raised as a result of changes to
multiprocessing: ergo multiprocessing.queue empty() and full() methods
are not currently getting test coverage
  * No obvious test rig for wsgui, so code is completely untested (!),
but I figured someone closer to wsgui could at least have my code for
reference, so included in the patch

Hi JP,

I experimented with stacklevel but to be honest nothing I saw appeared
greatly more useful than the default for the tests in question.

What form would the unit tests take? Trying to assert that empty() and
full() raised a deprecation warning? I'm not sure how I would go about that,
but I'll see what I can do.

Thanks,
-Tennessee

On Thu, Mar 5, 2009 at 3:00 PM, Jean-Paul Calderone
<report@bugs.python.org>wrote:

>
> Jean-Paul Calderone <exarkun@divmod.com> added the comment:
>
> Unit tests are a great thing as well.  Also, the deprecation warnings
> you've added are the really annoying kind.  They refer to users to the
> source of the deprecated methods themselves!  A vastly preferable use of
> the warnings system is to refer users to the *callers* of the deprecated
> methods.  Try passing different values for the stacklevel parameter of
> the warnings.warn function until you get a warning that is more helpful.
>
> ----------
> nosy: +exarkun
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue5420>
> _______________________________________
>

Quote:
Issues:
  * Noticed no warnings raised as a result of changes to
multiprocessing: ergo multiprocessing.queue empty() and full() methods
are not currently getting test coverage

? I need to check this.

You should test that the warnings are given by the deprecated methods.
Look at test_py3kwarn for an example of how to do that.

Now, with unit tests... :)

It's too late now for deprecation in 3.2...

I think the docstrings of empty and full should mention they’re obsolete, to make users of pydoc or other tools aware of the deprecation before they write code using them.