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
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
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
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
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.exe
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 (fd0) instead, but it's
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]
http://bugs.python.org/issue1415
Christian Heimes added the comment:
W/o the closed flag it's impossible to distinguish between closed fd and
invalid fd.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1415
__
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.
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 the
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 from an
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
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
__
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
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).
--
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
PY_STDERR_FILE is defined.
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
fact?
It happens when a script is run with pythonw.exe (pyw extension).
PythonW.exe isn't a console application but a GUI app which
programs on
Windows. For stderr I've to think about a better solution to avoid an
infinite loop (stderr.write() - exception - stderr.write() ...). Maybe
I could add some more methods to the dumb writer to make it more file
like and use it?
--
nosy: +amaury.forgeotdarc
title: py3k: pythonw.exe
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
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
New submission from Christian Heimes:
pythonw.exe fails to run with a runtime error. python.exe works as
expected. While the bug itself isn't serious it should either be fixed
or pythonw.exe be omitted from the next alpha release.
--
components: Windows
keywords: py3k
messages: 57342
Christian Heimes added the comment:
Update:
pythonw fails because the standard streams can't be initialized.
fileno(stdin), fileno(stdout) and fileno(stderr) are returning -2.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1415
.
When I run the script with python.exe (console), the script runs fine
and checks for new messages in perpetuity (as it should). However,
when I run the script with pythonw.exe (no console), the script
prematurely exits after 10 or 15 minutes. For those 15 minutes, it
works as it should, displaying
.
When I run the script with python.exe (console), the script runs fine
and checks for new messages in perpetuity (as it should). However,
when I run the script with pythonw.exe (no console), the script
prematurely exits after 10 or 15 minutes. For those 15 minutes, it
works as it should, displaying
message.
When I run the script with python.exe (console), the script runs fine
and checks for new messages in perpetuity (as it should). However,
when I run the script with pythonw.exe (no console), the script
prematurely exits after 10 or 15 minutes. For those 15 minutes, it
works
in perpetuity (as it should). However,
when I run the script with pythonw.exe (no console), the script
prematurely exits after 10 or 15 minutes. For those 15 minutes, it
works as it should, displaying tool tips when new messages arrive.
Furthermore, when it exits prematurely, it appears
Thanks to all, I learned something in each post.
When using py2exe to build an executable sys.executable does not
provide the name of the python interpreter but the name of the
executable generated by py2exe.
--
http://mail.python.org/mailman/listinfo/python-list
Metalone schrieb:
Thanks to all, I learned something in each post.
When using py2exe to build an executable sys.executable does not
provide the name of the python interpreter but the name of the
executable generated by py2exe.
When running the executable built with py2exe you might be
):
Test if file is on the os filesystem. This is necessary on windows,
when
starting python with pythonw.exe because in that case, the
stdout and stderr
are not real file and will create IOError when being flushed or when
more
than 4096 bytes are written
In particular I want to know how to tell if reading and writing to the
console can occur.
Something like
sys.isConsolePresent()
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 18, 2:56 pm, Metalone [EMAIL PROTECTED] wrote:
In particular I want to know how to tell if reading and writing to the
console can occur.
Something like
sys.isConsolePresent()
Look at sys.executable to find the name of the binary for the Python
interpreter.
--
On Oct 19, 7:56 am, Metalone [EMAIL PROTECTED] wrote:
In particular I want to know how to tell if reading and writing to the
console can occur.
Something like
sys.isConsolePresent()
Have you tried:
sys.stdin.isatty()
sys.stdout.isatty()
Graham
--
Does anyone know how to find where python is running from. I cant find
the answer to this anywahere on google or the docs. I know its there
because Ive seen ti done before. Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
Chaos wrote:
Does anyone know how to find where python is running from. I cant find
the answer to this anywahere on google or the docs. I know its there
because Ive seen ti done before. Thanks.
Hopefully It is still there. In module sys as executable.
Juergen
--
I wrote a python GUI with tkInter and installed it on a windows machinewith the .pyw extension, so it will be executed from pythonw.exe insteadof python.exe, since I didn't want the console window to appear.My application exits with a call to sys.exit. However, when this call isexecuted
I wrote a python GUI with tkInter and installed it on a windows machinewith the .pyw extension, so it will be executed from pythonw.exe insteadof python.exe, since I didn't want the console window to appear.My application exits with a call to sys.exit. However, when this call isexecuted
I wrote a python GUI with tkInter and installed it on a windows machinewith the .pyw extension, so it will be executed from pythonw.exe insteadof python.exe, since I didn't want the console window to appear.My application exits with a call to sys.exit. However, when this call isexecuted
I wrote a python GUI with tkInter and installed it on a windows machine
with the .pyw extension, so it will be executed from pythonw.exe instead
of python.exe, since I didn't want the console window to appear.
My application exits with a call to sys.exit. However, when this call is
executed under
()
#---
and ran it with pythonw.exe from python 2.3.4 on a machine running Windows NT
4.0. (I actually used Start Run and entered d:\python23\pythonw.exe
x:\app.pyw
rather than clicking on the app.pyw icon, but this shouldn't make a difference)
When the button is clicked, the application
of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Amir Helzer (eehelzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonw.exe should not flash DOS
Priority: 5
Submitted By: Manlio Perillo (manlioperillo)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdout problems with pythonw.exe
Initial Comment:
sys.version
'2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit
(Intel)]'
sys.platform
'win32'
sys.getwindowsversion()
(5, 1, 2600, 2
201 - 241 of 241 matches
Mail list logo
