[Python-Dev] Catching "return" and "return expr" at compile time

[Greg Ward]

On 07 September 1999, Greg Stein said:
> > Also, I would suggest that there should be some standard internal
> > mechanism for reporting errors rather than just calling
> > 'PySys_WriteStderr()'.  Something as simple as this would probably do
> 
> Why? Why not just use PySys_WriteStdErr() as your requested function? It
> can easily determine "oops. no stderr. let's do something else."

Hmm, that makes sense for the "what's the local equivalent of stderr?"
determination.  Probably that actually belongs in mywrite() (the static
function in Python/sysmodule.c that PySys_WriteStdout() and
PySys_WriteStderr() both invoke), so that the same thing can be done for
stdout and stderr.

However, I still think a separate function for printing
source-code-based warnings is a good idea.  This is mainly so that the
association from

  (filename, line_number, message)

to

  "warning: file %s, line %s: %s" % (filename, line_number, message)

is done in *one* place, rather than everywhere a warning message is
generated.  For instance, platforms that don't have stderr, but instead
pop up a window with all your compile-time warnings nicely formatted,
could take advantage of knowing the filename and line number separately
to nicely format those warnings.  (Of course, this argues *against*
putting the "what's the local equivalent of stderr?" determination in
the low-level mywrite() function... arg...)

> > Maybe sys.show_warnings? ;-)  (Of course, that's assuming a run-time
> > warning system in addition to the compile-time warnings of -t and Skip's
> > patch.)
> 
> There is no such thing as run-time vs compile-time warnings. You always
> have a compiler at run-time, and it can be used at any time. Therefore,
> you just have "(compilation) warnings" (I could imagine that people will
> come up with other kinds of warnings once the feature is provided).

Well, currently that's true, since currently Python's only warning is
the tab warning from -t -- clearly a compile-time warning.  (Is this
true?  I'm no expert on the internals, but I've certainly not seen any
other warnings from Python, and I've included plenty of bugs in my code
-- umm, just seeing if it would catch them, yeah that's it...)

However, one could certainly envision a world where Python issues
runtime warnings.  If my time machine were working, I'd zip back and
suggest to Guido that mistakes with the % operator should issue warnings
rather than raising exceptions.  (Ignore the language philosophy issue
and presume this would be worthwhile.)

There are probably other situations where, ignoring past history and
language philosophy, it would make sense to issue a warning and march on
ahead rather than blowing up immediately.  Sometimes Python has a bit of 
an itchy trigger finger for that ol' TypeError...

Anyways, the focus should probably be on compile-time warnings: I can't
think of any major runtime errors offhand that Python currently does
*nothing* about, so there's not a great need to go scattering the code
with runtime warnings.  But they *are* a theoretical possibility, and
there *is* a difference with compile-time warnings.


> I would suggest sys.warnings be a dictionary.
> 
> python -Wbad-return -Wlines-per-func=50
> 
> >>> print sys.warnings
> {'bad-return': None, 'lines-per-func': '50'}

Makes sense -- true to warn (possibly giving some extra meaning to
"truth", as in this example), and false to not warn.  Or maybe None to
not warn, not-None to warn.  Of course, if there are only compile-time
warnings, then modifying sys.warnings will only affect future imports,
execs, evals, etc.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913