[Python-Dev] Deprecation warnings in Python 2.7 (original) (raw)
Florent Xicluna florent.xicluna at gmail.com
Wed Mar 3 11:39:01 CET 2010
- Previous message: [Python-Dev] Deprecation warnings in Python 2.7
- Next message: [Python-Dev] Deprecation warnings in Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Deprecation warnings in Python 2.7
- Next message: [Python-Dev] Deprecation warnings in Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]