> [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
> I don't know either, so I'll copy you directly.
It seems to exist, but I don't read it - so this is a good idea.
[script, writing to sys.stderr and/or sys.stdout]
>>> Under Win98SE, and regardless of whether it writes to stdout or
>>> stderr, it dies when run under pythonw, and tb.txt contains this
>>> Died when trying to write byte 4097
>>> Traceback (most recent call last):
>>> File "wr.py", line 14, in ?
>>> IOError: [Errno 9] Bad file descriptor
>> I get exactly the same, on Win XP Pro, both for sys.stdout and
> 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>.
That may be, and the idea sounds even better if pythonw 'crashes' when
the bit bucket is full.