> Limiting the code to pythonw.exe instead of trying to install
> it in python20.dll was supposed to prevent damage to the use
> of Python in servers. Since pythonw.exe is a Windows (GUI) program,
> I am assuming there is a screen.
Sometimes _no_ screen at all is wanted - ie, no main GUI window, and no
console window. pythonw is used in this case. COM uses pythonw.exe in just
this way, and when executed by DCOM, it will be executed in a context where
the user can not see any such dialog.
However, I would be happy to ensure the correct command-line is used to
prevent this behaviour in this case.
Indeed, in _every_ case I use pythonw.exe I would disable this - but I
accept that other users have simpler requirements.
> Having said that, you may be right that there is some way to
> hang on a dialog box which can not be seen. It depends on what
> MessageBox() and GetForegroundWindow() actually do. If it seems
> that this patch has merit, I would be grateful if you would review
> the code to look for issues of this type.
There will be no issues in the code - it is just that Win2k will execute in
a different "workspace" (I think that is the term). This is identical to
the problem of a service attempting to display a messagebox - the code is
perfect and works perfectly - just in a context where noone can see it, or
dismiss it.
> > 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.
>
> There could be an API added to the winstdout module such as
> msg = winstdout.GetMessageText()
> which would return saved text, control its display etc.
I was thinking more of a "Py_GetTraceback()", which would return a complete
exception string.
Thus, embedders could write code similar to:
whatever = Py_BuildValue(...);
ret = PyObject_Call(foo, whatever);
...
if (!ok) {
char *text = Py_GetTraceback();
MsgBox(text);
}
Thus, with only a small amount of work, they have _complete_ control over
the output. However, I agree this doesnt really solve pythonw.exe's
problems.
> I do not view winstdout as a "newbie" feature, but rather a
> generally useful C-language addition to Python.
Hrm. I dont believe a commercial app, for example, would find this
suitable - they would roll their own solution.
Hence I see this purely for newbie users. Advanced users have complete
control now - a simple try/except block around their main code, and you are
pretty good. A builtin module for displaying a messagebox is as robust as
an experienced user needs to emulate this, IMO.
> I guess I am saying, perhaps incorrectly, that the mechanism provided
> will make further redirection of sys.stdout unnecessary 99% of the
> time.
Yes, I disagree here. IMO it is no good for a commercial, real app. As I
said, I see this as a feature so the newbie will not believe pythonw.exe is
broken. Advanced users can already do similar things themselves.
> Experimentation shows that Python composes tracebacks and
> error messages a line or partial line at a time. That is, you can
> not display each call to printf(), but must wait until the system is
> idle to be sure that multiple calls to printf() are complete. So this
> forces you to use the idle processing loop, not rocket science but
> at least inconvenient.
What "idle processing loop"?
> And the only source of stdout/err is tracebacks,
> error messages and the "print" statement. What would you do with
> these in a Windows program except display an "OK" dialog box?
Log the error to a file, and display a "friendly" dialog - possibly offering
to automatically submit a support request/bug report.
The casual user is going to be _very_ scared by a Python traceback. This is
a sin of a similar magnitude to those crappy applications with unhandled VB
exceptions.
IMO, nothing looks more unprofessional than an app that displays an internal
VB error message. Python is no different IMO. For real applications, there
is a good chance that the majority of your users have never heard of Python.
Thus, I don't believe your solution suitable for the real, professional,
commercial user. However, I agree that your solution does not prevent this
user doing the "right thing"...
But all this does keep me believing this is a "newbie" helper.
>
> If someone out there knows of a different example of sys.stdout
> redirection in use in the real world, it would be helpful if
> they would describe it. Maybe it could be incorporated.
Sure. Komodo to a file with a friendly dialog (sometimes ;-).
Pythonwin actually attempts a few things first - eg, not every exception
Pythonwin casues at startup should be logged.
Python services write unhandled errors to the event log.
I don't believe I have worked on 2 projects with the same requirement
here!!!
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