[Zope-dev] Re: python.exe vs pythonw.exe difference?

[Emile van Sebille]

Tim:
> [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.

To clarify, at that site I'm migrating from zope2.5/python2.1/win2k
box to zope2.7/python2.3/winxppro.  When "it used to work" I was
referring to my product running within zope as a service.  For initial
debugging in the new environment, I started in console mode.  Once
things stabilized, I started the service up and the problem surfaced.
Backtracking through the code I found the service starting the
application as per my earlier post with pythonw.exe which led me to
the direct comparison.

It did look like there'd been some significant refactoring going on
within zope and windows service interaction, but replicating the
effect directly using pythonw vs python seems to take that out of the
picture. (hence the post to the python list and not the zope list.  I
really should remember that python-dev is an open list now...)

At this point, I won't be back to that site before next week, although
I may take some time to test this weekend.  It sounds like I should
rework any areas that spew output to the console.  Is there something
better than checking os.path.basename(sys.executable)?

>
> ideas-ain't-code-ly y'rs  - tim

That'd be too easy!  Just ask that other Tim...

Emile van Sebille
emile at fenx dot com
emile at fenx.com