On 1/8/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
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.
Well, yes, that's why I want to add it to -W :) I mean to suggest that 'py3k' should just be a warning category. And not a special case. Should we also add a PYTHONWARNINGS environment variable? Makes sense, I suppose.
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?
Yes, I mean for the warnings for ``, tabmixing and input() to be enabled always, and the rest just when enabling py3k warnings. And yes, we'd need a way to turn the tabmix-warnings off; in the p3yk branch, I made '-t' and '-tt' be a no-op (since it errors by default), and introduces '-ttt' to turn tab-errors into warnings. The main reason I've not made tabmix-warnings the default in the trunk is that I couldn't think of the right option to turn it back off :) It doesn't use the warnings mechanism (mostly because it has to warn during parsing, when usually no python code is running) so '-W tabs:ignore' doesn't work. Then again, maybe with Neal's warning framework in C, we can make it work for the parser, too. Would be luvly for SyntaxWarnings too :) 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).
For p3yk-warnings, we should warn about both, but I'm not sure about the usefulness of warning about print... there's no upgrade path, as such. At least not for all print's features.
__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.
Me, too. That's the 'optional, default off' thing. I was talking about making things warn in absense of -Wpy3k too. 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...
We have that: -W error :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
