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@fenx.com