---cut test.py---
print("-1-")

open("-2-", "w").write("-3-")
---cut test.py---


> C:\Python27\pythonw.exe test.py > -4-
> type -4-
-1-

> C:\Python27\pythonw.exe test.py 2> -4-
> type -4-
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

> C:\Python27\python.exe test.py 2> -4-
-1-
>type -4-
>


This may also affect subprocess calls under pythonw.exe  I am running Python 2.7.3

This subprocess.communicate() call fails with pythonw.exe

--cut testhg.py--
import subprocess

hg = "hg"
output, _err = subprocess.Popen([hg, 'id', '-nib'],
                   stdout=subprocess.PIPE).communicate()
open("-hg-", "w").write(output)
--cut testhg.py--


When testhg.py is run with python.exe from cmd.exe session, the -hg- file is created ok. When pythonw.exe is used, nothing happens. When redirecting stderr from pythonw.exe with:

C:\Python27\pythonw.exe testhg.py 2>1

1 contains the following stacktrace:
Traceback (most recent call last):
  File "testhg.py", line 5, in <module>
    stdout=subprocess.PIPE).communicate()
  File "C:\Python27\lib\subprocess.py", line 672, in __init__
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)
  File "C:\Python27\lib\subprocess.py", line 787, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\Python27\lib\subprocess.py", line 826, in _make_inheritable
    _subprocess.DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid

This was meant to be a separate issue. :/

Yes, in pythonw.exe the C stderr is not really usable, and this leads to unpredictable results.
It's difficult to fix in python2 though; python3 has fixed this issue, but in a way that cannot be backported.

Some workarounds:
- don't use pythonw.exe in a console, it's meant to be a *windows* application, without standard streams. I'm actually surprised of the behavior of your first example.

- use python3, where pythonw will set sys.stderr to None, and prints will be silently discarded.

It is not about modifying Python in general, it is about patching pythonw.exe or subprocess or documenting how to make subprocess calls compatible with pythonw.exe


"don't use pythonw.exe in a console"

And how to debug the issue? Maybe the only solution in not using pythonw.exe at all if you want *windows* app solution, and do custom management of hidden windows.

http://code.google.com/p/spyderlib/source/browse/CHANGELOG
http://code.google.com/p/spyderlib/source/browse/spyderlib/utils/windows.py

The proper solution if you use pythonw.exe is to define sys.stdout/sys.stderr yourself in pythonw.exe::
    sys.stdout = open('c:/temp/output.txt', 'w')

IOW, do the redirect from inside the program, don't rely on the shell which (by design?) does not work correctly with "/subsytem:windows" binaries.
Again, this is a workaround for 2.7, because no backward-compatible fix could be found.

I am not using pythonw.exe, it is the option users prefer to run the program. 

pythonw.exe is a binary, how do you propose to patch that? Or is it translated to .exe with RPython?


Can you be more specific  what shell  does not work correctly, what exactly does not work correctly, and what is the backward-incompatible behaviour that you want to avoid?

pythonw.exe is meant to suppresses the terminal window on startup (console window to be exact), but not to kill vital streams for an application. I posted links Spyder IDE source to show how it should be done.

RPython... let's be serious. The code of pythonw.exe is very simple, see PC/WinMain.c.

No, pythonw.exe is not "meant to suppresses the terminal window on startup". This is only a consequence of being a "windows application". There is a lot of documentation about this, for example:
http://comsci.liu.edu/~murali/win32gui/Win32Apps.htm

- python.exe is a regular console application, with a main() function.
- pythonw.exe is a gui application, with a WinMain() function; as a consequence, stdout/stderr won't work properly.

Again, it's a won't fix for 2.7, unless someone comes with a patch. But this has already been tried, and be careful, different versions of the msvcrt differ in behavior here.