python.exe vs pythonw.exe difference?

[Bengt Richter]

On Tue, 2 Mar 2004 14:06:36 -0500, "Tim Peters" <tim.one at comcast.net> wrote:

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