[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)
Paul Moore p.f.moore at gmail.com
Thu Oct 1 10:58:59 CEST 2009
- Previous message: [Python-Dev] Python 2.6.3
- Next message: [Python-Dev] OT: detatching from terminal (was: Re: PEP 389: argparse - new command line parsing module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2009/9/30 Robert Kern <robert.kern at gmail.com>:
I am blissfully unaware of the problems Paul mentioned about Windows GUI-mode programs.
:-)
I'm not sure what would make a program "GUI-mode" or not. Certainly, I have written Python programs that use wxPython and PyQt on Windows that print to stdout/stderr, and they appear to work fine.
It's the difference between using python.exe and pythonw.exe. There's a flag in the executable header saying whether the executable is "console mode" or "gui mode".
GUI mode programs are run (by the OS) without a console (or if run from a console prompt, they automatically detach from that console, much like Unix programs which fork themselves to leave the terminal group (did I get the terminology right?) but done by the OS). As a result, the program has no valid stdin/out/err handles. Any attempt to write to them causes the program to crash.
Traceback (most recent call last): File "hello.py", line 13, in main() File "hello.py", line 7, in main sys.stdout.flush() IOError: [Errno 9] Bad file descriptor
(Question - is it ever possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!)
Paul.
- Previous message: [Python-Dev] Python 2.6.3
- Next message: [Python-Dev] OT: detatching from terminal (was: Re: PEP 389: argparse - new command line parsing module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]