[Python-Dev] Create a synthetic stdout for Windows?

[Mark Hammond]

> Is this a good idea?  If so, is the implementation optimal

Im really on the fence here.  Note however that your solution does not solve
the original problem.  Eg, your example is:

> On December 30, 2000 gerson.kurz@t-online.de (Gerson Kurz) writes:
>
>    If I embedd Python in a Win32 console application (using
>    Demo\embed.c), everything works fine. If I take the very same piece

But your solution involves:

> The file WinMain.c calls PyWin_StdoutReplace() before it
> calls Py_Main(), and PyWin_StdoutPrint() afterwards.  This

Note that the original problem was _embedding_ Python - thus, you need to
patch _their_ WinMain to make it work for them - something you can't do.

Even if PyWin_StdoutReplace() was a public symbol so they _could_ call it, I
am not convinced they would - it is almost certain they will still need to
redirect output to somewhere useful, so why bother redirecting it
temporarily just to redirect it for real immediately after?

Finally, I am slightly concerned about the possibility of "hanging" certain
programs. For example, I believe that DCOM will often invoke a COM server in
a different "desktop" than the user (this is also true for Services, but
Python services don't use pythonw.exe).  Thus, a Python program may end up
hanging with a dialog box, but in the context where no user is able to see
it.  However, this could be addressed by adding a command-line option to
prevent this new behaviour kicking in.

I would prefer to see a decent API for extracting error and traceback
information from Python.  On the other hand, I _do_ see the problem for
"newbies" trying to use pythonw.exe.

So - I guess I am saying that I don't see this as optimal, and it doesnt
solve the original problem you pointed at - but in the interests of making
pythonw.exe seem "less broken" for newbies, I could live with this as long
as I could prevent it when necessary.

Another option would be to use the Win32 Console APIs, and simply attempt to
create a console for the error message.  Eg, maybe PyErr_Print() could be
changed to check for the existance of a console, and if not found, create
it.  However, the problem with this approach is that the error message will
often be printed just as the process is terminating - meaning you will see a
new console with the error message for about 0.025 of a second before it
vanishes due to process termination.  Any sort of "press any key to
terminate" option then leaves us in the same position - if no user can see
the message, the process appears hung.

Mark.