[Python-Dev] Catching "return" and "return expr" at compile time
email@example.com (Skip Montanaro)
Tue, 7 Sep 1999 12:41:27 -0500 (CDT)
[ ...Lot's of stuff about details of warning implementation snipped... ]
That's why I only provided the code to check for inconsistent use of
returns, not the flag to turn it on and off!
In a message I accidentally sent only to Guido and myself on the subject, I
outlined my take on things, which really does about exhaust my
knowledge/interest on how/when to enable warnings:
Guido> I'm not sure I like the fact that you can't turn it off --
Guido> traditionally, Python has had a "no warnings" policy. That has
Guido> been diluted a bit (python -t prints warnings) but so far it has
Guido> been the default.
The only reason for not being able to turn it off was that would require
introducing some sort of -w flag, which wasn't the point of the exercise.
We can have the -w/-t/-W discussion now. I haven't any particular opinion
on the best way to do it, although I would much prefer it be a run-time as
opposed to compile-time option. One other issue might be whether or not to
ignore an existing .pyc file and always recompile .py's if warnings are
enabled. Of course, we're still all adults here (I think), so perhaps it's
sufficient to remind people in the docs to delete the desired .pyc files
before running with warnings enabled.
Guido> I'm wondering if we should introduce a general '-w' flag to turn
Guido> on warnings like this (which would subsume -t)? Or perhaps there
Guido> should be a -W flag ("no warnings") and warnings should be the
-w sounds fine to me.
Guido> There are also platform problems, e.g. on the Mac, stderr doesn't
Guido> always exist, and on Windows, it doesn't exist if pythonw.exe is
Perhaps on those platforms a file could be opened in a standard location to
catch stderr (I presume you can detect the lack of stderr at run-time?).
While that would force some (more) Unix conventions on programmers on those
platforms, it would also provide more cross-platform uniformity.