> > 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 to look... > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4