> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4