problem without stdout shown...somewhere?

wxPython Users
1

I just noticed an odd problem (well, odd for me at least). I have
been writing apps with Boa Constructor, and things are fine.
(WinXP, wxPython 2.8.7.1., Python 2.5, Boa 0.6.1). I run
the apps to test them from within Boa.

Usually I can also double click on the icon for the app in its
folder and launch it and it runs fine that way, too. But just
now though I find a problem when doing this...

In my app that runs 100% fine within Boa, when I go to add a
matplotlib plot into a wxAUINotebook, all the contents of that
frame disappear and I'm left with a grey frame--but the other
frame in the app is still working.

BUT, it still works perfectly from within Boa. It also will
work if I set app = wx.PySimpleApp() to be
app = wx.PySimpleApp(1) so that the little stdout frame
pops up. Lastly, it will run fine if I run it from the command
prompt.

In all cases, it is only working at that point if the stdout
output "has somewhere to go" and is messing up at that
point if it doesn't.

I hope this problem makes sense to someone. If not, I will
try to make a SRS (small, runnable sample). This is probably
a very basic Python thing that I've just not encountered yet.

Thanks,
Che

2

The problem is a windows one: in certain contexts there IS no stdout (or stderr
even). In particular if you start the app with “pythonw” instead of “python”, its

a console-less windowed application. Instead of just having stdout/stderr that
aren’t shown in a window – Windows is not bothering to give the app stdout
stderr at all.

Thus attempting to write to it is throwing an exception.

You can either re-assign sys.stdout to a file or use Python’s “logging”
package to capture the output and redirect it that way.

–Stephen

···

On Fri, Jan 23, 2009 at 11:46 PM, C M cmpython@gmail.com wrote:

I just noticed an odd problem (well, odd for me at least). I have

been writing apps with Boa Constructor, and things are fine.

(WinXP, wxPython 2.8.7.1., Python 2.5, Boa 0.6.1). I run

the apps to test them from within Boa.

3

You can either re-assign sys.stdout to a file or use Python’s “logging”

package to capture the output and redirect it that way.

E.g. (if that wasn’t clear): something like this early in your app initialization:

import sys
class FakeFile:

def __init__(self, fp):
    self._fp = fp

def write(self, data):
    try:
        self._fp.write(data)
    except:
        pass

def flush(self):
    try:

        self._fp.flush()
    except:
        pass

sys.stdout = FakeFile(sys.stdout)
sys.stderr = FakeFile(sys.stderr)

… will generally make it so your program Just Works regardless of if its launched w/ pythonw or python, and still let you use “print” and regular output data when you want to instead of having to use “logging”. (Personally I recommend switching to logging sooner as opposed to later)

–Stephen

4

Stephen,
Thank you very much! That worked beautifully, and your explanation
has taken me back out of the Twilight Zone.

Thanks also for the tip about logging; I have not done logging before,
but I just Googled a bit and am about to learn about it here:
http://blog.tplus1.com/index.php/2007/09/28/the-python-logging-module-is-much-better-than-print-statements/

Che

···

On Sat, Jan 24, 2009 at 12:03 PM, Stephen Hansen <apt.shansen@gmail.com> wrote:

You can either re-assign sys.stdout to a file or use Python's "logging"
package to capture the output and redirect it that way.

E.g. (if that wasn't clear): something like this early in your app
initialization:

import sys
class FakeFile:
    def __init__(self, fp):
        self._fp = fp

    def write(self, data):
        try:
            self._fp.write(data)
        except:
            pass

    def flush(self):
        try:
            self._fp.flush()
        except:
            pass

sys.stdout = FakeFile(sys.stdout)
sys.stderr = FakeFile(sys.stderr)

... will generally make it so your program Just Works regardless of if its
launched w/ pythonw or python, and still let you use "print" and regular
output data when you want to instead of having to use "logging". (Personally
I recommend switching to logging sooner as opposed to later)

--Stephen