[Python-3000] Warning for 2.6 and greater

Anthony Baxter anthony at interlink.com.au
Mon Jan 8 13:29:42 CET 2007


On Monday 08 January 2007 22:53, Thomas Wouters wrote:
> I would prefer -Wpy3k, or the corresponding
> warnings.filterwarnings call, and just not warn in too many
> (used) places.

-W seems like an option. We can add other -W options later
(for instance, -W tabs). Hm. -W already has a meaning, though.
Should we also add a PYTHONWARNINGS environment variable?

> Also, there are a number of things I'd like to 
> warn for, regardless of -3/-warn3/-Wp3yk, that will be errors in
> py3k, but are already a bad idea: mixing tabs and spaces
> (basically make -t the default), using `` (the repr syntax),
> using input().

I haven't looked into hooking into the compiler yet to detect ``. 
The others seem OK to add. 

> (Also on my warn-TODO for 2.6 are coerce(), __get/set/delslice__,
> integer division, 

I'll just make -W py3k also enable -Qwarn (and -t, for the tabs).
Or do you want to make -t the default for 2.6? In that case, should 
we add an option to turn it off? Hm. -T, maybe?

I'm not sure whether we should try and warn about 'print' becoming a 
function. We should also consider things like intern() and 
compile() (if they are to move to sys).
> __cmp__, passing floats to getargs.c's integer 
> functions, exceptions not deriving from BaseException, use of
> file.xreadlines(), and implicit relative imports, but those
> should all (probably) be optional, default off.)

See, I'd like to make -W py3k enable _all_ of these warnings. If we 
also want to add finer-grained warnings, we could do that, too (but 
I'm not so sure about that). 

Do we also want to add an option to promote these warnings to actual 
errors? I think leaving that for 2.7 is a good idea...

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


More information about the Python-3000 mailing list