[Python-3000] Warning for 2.6 and greater
Anthony Baxter
anthony at interlink.com.au
Wed Jan 10 05:24:05 CET 2007
cc'ing python-dev - followups should probably go there, rather than
the p3yk list.
So here's my latest plan:
- Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning
(or maybe just of Warning)
- Add a -W py3k shortcut, which is the same as
"-W once:Py3kDeprecationWarning"
- Add a C int (as in previous patch) that is also set to 1 if the
command line flag is specified. This is because there's no easy or
quick way to check that a warning has been set - and calling into
the warnings code is expensive, even if the C code warnings module
is done. We can revisit this if the C version of warnings grows
some extra features to make this less awful.
For 2.6, we make a single -t (mixing tabs and spaces) the default,
and maybe add -T to suppress this.
DeprecationWarning for 2.6:
- `foo` (backticks)
- input()
The following are the list of things that get
Py3kDeprecationWarnings (so far):
integer division - make "-Q warn" the default when -W py3k specified
coerce() - going away
apply() - going away
intern() - moving to sys (we should also move it to sys, and make
intern() - call sys.intern())
file.xreadlines() - going away
dict.has_key() - use 'in dict'
<> - use != (aka "MakeBarryCryDeprecationWarning")
__(get|set|del)slice__
__coerce__ - gone
__(div|idiv|rdiv)__ - no replacement?
__nonzero__ - we should add __bool__ to 2.6, and then warn people.
Not sure we can rename the nb_nonzero slot, though.
For the various __foo__ slots, it might be nice to warn when they're
defined, rather than used, but I've not looked into how hard this
would be to do, or whether it would still work with .pyc files and
the like. On the other hand, warning on use might also let us pick
up when C code modules use the same functions.
There's other changes that are probably too hard to warn about,
because there's not an easy replacement - the exec and print
statements come to mind here.
Comments? What else should get warnings?
Anthony
More information about the Python-3000
mailing list