[Python-Dev] Deprecation warnings in Python 2.7

[Florent Xicluna]

2010/3/3 Raymond Hettinger <raymond.hettinger at gmail.com>:
>
> -1 for several reasons.
> 1) We've advertised -3 as part of TheOneTrueWay(tm).  It's a core part of
> our transition story, so we should keep that as clean/consistent as
> possible.  Deprecating the -3 switch seems like shooting ourselves in the
> foot.

Instead of deprecating the -3 switch, we can change it to a useful
alias (see below).

> 2) There is some chance that there will be a 2.8, so it isn't helpful to
> burn down our bridges.
> ISTM, nothing is currently broken and in need of "fixing" in 2.7.
> I don't see any advantage to conflating py3k warnings with other
> deprecations.
>

IMHO, the current deprecation and warning mechanism is not far from a
Rube Goldberg machine.
There's many options available, and it's not obvious both for the core
developer and for the end user.

On the python interpreter side, you have many options for the careful developer:
 -Wdefault: display all warnings
 -3:        display all warnings except ImportWarning and
PendingDeprecationWarning
 -Qwarn     does nothing if -Wd is omitted, else warn about 2/1 or 2L/1
 -Qwarnall  does nothing if -Wd is omitted, else warn about 2.0/1 or 2j/1
 -b/-bb     (undocumented), warns about u'' == bytearray('')
 -t/-tt     warns about tab inconsistencies

Why -Qwarn needs -Wd to show its warnings?
And you should know that -3 implies -Qwarn, but it still mask
PendingDeprecationWarnings.
So you will not see the PendingDeprecationWarning issued by
cgi.parse_qs or shutil module (for example).

At the same time, you could notice that the mhlib module yields a
non-py3k DeprecationWarning about its removal in 3.0.

And now you want to compare unicode with bytes (ok, it's a very bad
idea, but it may happen when you sort dictionary keys, for example):

~ $ ./python

>>> u'\xff' == bytearray('\xff')    # No warning?
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False

~ $ ./python -Wd -bb

>>> u'\xff' == bytearray('\xff')    # It should raise an error because of '-bb'
__main__:1: BytesWarning: Comparison between bytearray and string
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False

Yeah, it may be confusing... "Comparison between bytearray and string"
is not really the correct message in 2.7. And why to keep these 2
warnings categories which are not used anywhere else in Python source
code?  The behavior should be consistent between these 2 warnings, and
they may share the same category. Why we don't use a RuntimeWarning
here?

I still support the simplification of the warnings mechanism:
 * -Qwarn/-Qwarnall should imply
    -Wdefault -Wignore::ImportWarning -Wignore::PendingDeprecationWarning
    (same as current -3 behavior)
 * BytesWarning should be replaced by UnicodeWarning or RuntimeWarning
(and -b deprecated)
 * -Wdefault should show all warnings (including py3k warnings)
 * -3 should show the PendingDeprecationWarning in addition to its
current behavior.
   (i.e. an alias for -Wdefault -Wignore::ImportWarning)

-- 
Florent