python.exe vs pythonw.exe difference?

[Thomas Heller]

"Tim Peters" <tim.one at comcast.net> writes:

> [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.

It seems to exist, but I don't read it - so this is a good idea.

> [Tim]
[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
>>> 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>.

That may be, and the idea sounds even better if pythonw 'crashes' when
the bit bucket is full.

> ideas-ain't-code-ly y'rs  - tim

Sure ;-)

Thomas