[issue1415] py3k: pythonw.exe fails because std streams a missing

Amaury Forgeot d'Arc added the comment: > As far as I can see print() works if sys.stdout is either None > (discard output ASAP) or a file like object. Even > print(file=syst.stderr) works. Ah, I prefer this. > sys.stdout.write() is going to fail when sys.stdout is None > but that's not my con

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: As far as I can see print() works if sys.stdout is either None (discard output ASAP) or a file like object. Even print(file=syst.stderr) works. sys.stdout.write() is going to fail when sys.stdout is None but that's not my concern. It's another well documented

[issue1415] py3k: pythonw.exe fails because std streams a missing

Amaury Forgeot d'Arc added the comment: Is it the only possibility? On Windows, it is quite common to print to stdout for debugging purposes, then deploy the application with pythonw.exe which suppresses the console. Without any change to the code. Most pygame programs I know work this way, and

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Since r58962 it doesn't ;) __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1415] py3k: pythonw.exe fails because std streams a missing

Amaury Forgeot d'Arc added the comment: (Sorry, I cannot test just now) What happens if pythonw.exe calls the print() function? Please tell me that it does not throw an exception. __ Tracker <[EMAIL PROTECTED]> __

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: I consider the bug fixed and closed. Objections? -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Fixed in r58959 I followed your wish and set sys.stdin, stdout and stderr to None together with __std?__. I also kept the check for fd < 0 in fileio_init(). A negative fd still raises the correct error with errno 9 (bad file descriptor). -- resolution

[issue1415] py3k: pythonw.exe fails because std streams a missing

Guido van Rossum added the comment: > I don't want to treat the fd differently. I want to return a sensible > error message that is different from "file closed" when the fd is invalid. Doesn't sound too important. Anyway, from which call do you want to issue different messages? I'd rather see

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: The mail gateway swallows examples: >>> import sys >>> sys.stderr = None >>> raise Exception("msg") >>> del sys.stderr >>> raise Exception("msg") object : Exception('msg',) type: Exception refcount: 4 address : 0x839d274 lost sys.stderr _

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Guido van Rossum wrote: > I still don't understand. Why do you need to treat a closed fd > different from an invalid fd. In both cases you can't use it and you > shouldn't close it. I don't want to treat the fd differently. I want to return a sensible error me

[issue1415] py3k: pythonw.exe fails because std streams a missing

Guido van Rossum added the comment: > > I don't understand. When does the difference matter? > > When the check for fd < 0 is removed from fileio_init() there is no way > to tell if fd < 0 means fd closed or invalid fd. I still don't understand. Why do you need to treat a closed fd different fro

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > I don't understand. When does the difference matter? When the check for fd < 0 is removed from fileio_init() there is no way to tell if fd < 0 means fd closed or invalid fd. In order to fix th

[issue1415] py3k: pythonw.exe fails because std streams a missing

Guido van Rossum added the comment: I don't understand. When does the difference matter? On Nov 12, 2007 10:14 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > W/o the closed flag it's impossible to distinguish between closed fd and > invalid fd. _

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: W/o the closed flag it's impossible to distinguish between closed fd and invalid fd. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1415] py3k: pythonw.exe fails because std streams a missing

Guido van Rossum added the comment: IMO you don't need the 'closed' flag and you should continue to test for fd < 0. Whether it's -1 or -2, you still can't write to it... __ Tracker <[EMAIL PROTECTED]> __

[issue1415] py3k: pythonw.exe fails because std streams a missing

Amaury Forgeot d'Arc added the comment: Doh, you're right: > c:\python24\pythonw -c "import sys;print sys.stderr.fileno()"|more -1 > c:\python24-vc8\pythonw -c "import sys;print sys.stderr.fileno()"|more -2 /me needs to get the code of msvcrt7. We could simply check for (fd<0) instead, but it's

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: The patch is a good idea. However it doesn't work for VS 2003 and MSVCR71: import sys f = open("stderr.txt", "w") f.write("stdin: %i\n" % sys.stdin.fileno()) f.write("stdout: %i\n" % sys.stdout.fileno()) f.write("stderr: %i\n" % sys.stderr.fileno()) > pythonw

[issue1415] py3k: pythonw.exe fails because std streams a missing

Amaury Forgeot d'Arc added the comment: I made some checks with the vc2005 (msvcr80) runtime library: - fd==-2 corresponds to the _NO_CONSOLE_FILENO constant. A comment in the CRT code says: /* * For stdin, stdout & stderr, we use _NO_CONSOLE_FILENO (a value * different from _INVALI

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Guido van Rossum wrote: > Hmm... In internal_close() there's still a test for self->fd >= 0. I'm > not sure if this is an oversight or intentional. I'll check it later. The patch still contains some debugging code that redirects stdout and stderr to a file wh

[issue1415] py3k: pythonw.exe fails because std streams a missing

Guido van Rossum added the comment: Hmm... In internal_close() there's still a test for self->fd >= 0. I'm not sure if this is an oversight or intentional. Also, I don't understand under what circumstances fds < 0 can occur. I presume this is only on Windows. Can you point me to docs for this fa

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: The new patch fixes the startup problem with pythonw.exe on Windows. I still wonder if print(sometest) is raising an exception when stdout is not available. Added file: http://bugs.python.org/file8731/py3k_fileio_fixes.patch __

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: PATCH: * remove the analogy fd < 0 -> file is closed from _fileio.FileIO * added new flag closed to _fileio.FileIO * renamed closefd to close_fd to distinguish it from closed * make it impossible to instantiate another stdprinter * added repr and fileno methods

[issue1415] py3k: pythonw.exe fails because std streams a missing

Christian Heimes added the comment: Congratulations Amaury and welcome on board! :) I like to get your opinion on the problem. So far I've figured out that Windows doesn't create the std streams for Windows WinMain() programs. As first step towards the solution I like to separate the close check