[Python-Dev] Catching "return" and "return expr" at compile time
Guido van Rossum
Tue, 07 Sep 1999 19:05:19 -0400
> > 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?).
> Not really - there are 2 scenarios here. pythonw.exe, for example, always
> has a valid stdout handle - it just goes nowhere. When Python is embedded
> in certain COM servers (such as ASP), the stdout handle is invalid -
> operations on it will fail (perversely, this also means a single "print"
> statement in your Python code can raise an exception and make your code
> fail - and seeing as print statements are the debugging state of the art at
> the moment, this is less than ideal - but I digress)
> So Im not sure we can check this reasonably at runtime - invalid handles
> are easy, but valid handles that go nowhere useful (as in pythonw.exe, and
> therefore the majority of cases we care about) is obviously difficult.
> OTOH, pythonw.exe doesnt print tracebacks either. Although not ideal,
> people arent loudly complaining about this - they know to develop and debug
> using python.exe. As the warnings we are discussing are compile time
> warnings, we could simply document that they should run "compileall" over
> their scripts to generate the warnings before attempting to embed it in
> some sort of wierd system.
Hmm... Perhaps pythonw.exe could use freopen() to point stdout and
stderr to a log file in a temp directory? The wizards will know where
> On my third hand, I would _really_ like to see this in a lint tool rather
> than in the core. I realize there is no such tool at the moment, but IMO
> is where we should be heading. Skip's return statement warnings are fine
> and a nice addition, but in my experience account for a trivial number of
> my errors. Stuff like warning about a variable name used only once, for
> example, will probably never get into core Python but in my opinion is far
> more valuable. So adding this "-w" switch is fine, but still doesnt give
> us the framework we need to actually create a truly useful package of
> warnings for the Python developer.
> [And I am slowly and painfully starting work in this - a lint tool based on
> the Python parser module. Dont hold your breath though :-]
Eventually, I also plan to have some kind of lint in IDLE. If the
CP4E money comes, I'll start working on that for earnest...
--Guido van Rossum (home page: http://www.python.org/~guido/)