[Thomas Heller]
[I'm currently reading python-list via the gmane nntp interface, I
don't know whether there really is a gmane.comp.web.zope.devel
newsgroup]
I don't know either, so I'll copy you directly.
[Tim]
...
Here's a Python program to try:
"""
import sys
if 1: # edit to 1 for stdout, 0 for stderr
console = sys.stdout
else:
console = sys.stderr
import traceback
tb = file('tb.txt', 'w')
try:
i = 0
while True:
i += 1
console.write('.')
except:
print >> tb, "Died when trying to write byte", i
traceback.print_exc(file=tb)
tb.close()
"""
Under Win98SE, and regardless of whether it writes to stdout or
stderr, it dies when run under pythonw, and tb.txt contains this
after:
Died when trying to write byte 4097
Traceback (most recent call last):
File "wr.py", line 14, in ?
console.write('.')
IOError: [Errno 9] Bad file descriptor
[Thomas]
I get exactly the same, on Win XP Pro, both for sys.stdout and
sys.stderr.
That's good to know! Thanks.
...
Since it seems XP shows the same behaviour than win98SE, has the
behaviour of Python changed? Were IOErrors ignored on sys.stdout or
sys.stderr in earlier versions?
No, the same program fails the same way here under pythonw 2.2.3 and 2.1.3
(with s/file/open/ and s/True/1/). The OP wasn't clear about what "it"
meant, though (in "it used to work"). I guess it's most likely he meant
running Zope 2.5 as a service used to work, not that running Zope 2.5 by
hand from a DOS box with pythonw used to work, but don't know. It's
certainly possible that something relevant changed in Zope, and/or in how
Zope tries to live with Windows services.
IIRC, /F first proposed that pythonw.exe should create a console to
have a place to show tracebacks. Sounds like a good idea to me.
Some way of having pythonw not drop output into the bit bucket has sounded
like a good idea to everyone for about a decade now <wink>.
ideas-ain't-code-ly y'rs - tim
You can call AllocConsole safely at the last moment before spewing text, I think,
and without even checking if there already is one (I think it will quietly do nothing
if there is, IIRC from old Delphi days).
I don't think people want to see console windows along with their GUIs when things are normal,
but post mortem is another thing, and this is a simple call. Also it gives you a handy separate
window to put debug messages to just by using print, which can be handy with
if __debug__: -conditional code or temporary hacks.
_____________________________________________________________________________
The AllocConsole function allocates a new console for the
calling process.
BOOL AllocConsole(VOID)
Parameters
This function has no parameters.
Return Value
If the function succeeds, the return value is TRUE. If the
function fails, the return value is FALSE. To get extended
error information, call GetLastError.
Remarks
A process can only be associated with one console, so
AllocConsole fails if the calling process already has a
console. A process can use the FreeConsole function to
detach itself from its current console, and then it can call
AllocConsole to create a new console. If the calling process
creates a child process, the child inherits the new console.
AllocConsole also sets up standard input, standard output,
and standard error handles for the new console. The standard
input handle is a handle to the console's input buffer, and
the standard output and standard error handles are handles
to the console's screen buffer. To retrieve these handles,
use the GetStdHandle function.
This function is primarily used by graphics applications to
create a console window. Graphics applications are
initialized without a console. Console applications are
normally initialized with a console, unless they are created
as detached processes (by calling the CreateProcess function
with the DETACHED_PROCESS flag).
See Also
CreateProcess, FreeConsole, GetStdHandle
_____________________________________________________________________________
AllocConsole should be easy to call through one of the win32 interfaces.
Maybe we should just make a DLL that would just do that and nothing else when imported.
Re Emile's situation, I think there may be an additional factor. I.e., output from a windows
service to an interactive window requires a special checkbox somewhere in the service setup,
I think, since services normally run as a non-interactive process with separate user identity
from whoever might be locally logged on.
That bit in your '.' output suggests to me that there's a 4k buffer write being triggered and
that is the thing that runs into no place to write. I wonder if it wouldn't trigger earlier with
newlines or explicit flush or -U ?
HTH
Regards,
Bengt Richter
