[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