[Python-Dev] [Python-3000] Warning for 2.6 and greater

[Anthony Baxter]

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