New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
print in pythonw raises silent exception when no console available #38179
Comments
platform: win2k the test case works fine when the script is run with print (or to be more exact sys.stdout.write) should be test case: output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
File "test_case.py", line 5, in ?
print 'a',
IOError: [Errno 9] Bad file descriptor |
Logged In: YES Mark, give a rip <wink>? |
Logged In: YES I struck this years ago, but was in a quandry. On one hand, However, I see the point that print is so basic that is So I am afraid that, no, I don't give a rats <wink>. Unless |
Logged In: YES I can swing either way on this, or even a third: open text BTW, making stdout and stderr /dev/null workalikes is |
Logged In: YES then please throw a meaningful exception at first byte |
Logged In: YES and to say something FOR noop: yes, but someone would use print in an application and still btw: the microsoft implementations (visual studio) of printf i would consider it best, to make sys.stdout.write a noop |
Logged In: YES I just submitted a bug report ([ 710041 ] sys.stdout IOError Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit Calls to the write() methods seem to discard the data, which BUT, when the write() method is called with more than This IOError happens when write()ing even one character I work around it by defining my own bit-bucket for |
Logged In: YES Yet another alternative: when soneone writes to stdout or Personally, I would prefer just discarding the output. This Note that it is still posible to capture the stdout and |
Python 3.0 already discards the output in this case (see bpo-1415): I think this is the correct behavior, but I'm not sure this can be |
FWIW: I don't know if it changes anything, but when deploying Django projects on some clients who uses Windows as server, I'm using this piece of code to workarround this issue: ## Fixes "IOError: [Errno 9] Bad file descriptor" when in pythonw.exe of Windows if sys.platform.find('win') != -1 and sys.executable.find('pythonw') != -1:
blackhole = file(os.devnull, 'w')
sys.stdout = sys.stderr = blackhole Is not my intention to remove print statments neither to send they to a file. For this I'm using logging module. I really expect they to be silently ignored, bothering not my user. |
Works fine with pythonw on 2.6 and 2.7. |
No, nothing changed in this aspect since python 2.2. |
@Amaury I tested with Windows Vista and the latest 2.6 and 2.7 maintainance releases, what did you use? |
I use Windows XP. |
Ah I was misreading things, I too can confirm that it is still a problem. |
This is indeed reproducible in Python 2.7. The following unittest will expose it. However, patching sys.std* to None will break diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
old mode 100644
new mode 100755
--- a/Lib/test/test_os.py
+++ b/Lib/test/test_os.py
@@ -58,6 +58,19 @@
new = sys.getrefcount(path)
self.assertEqual(old, new)
+ @unittest.skipUnless(sys.platform == 'win32',
+ 'test specific to Windows console')
+ def test_print_no_stdout(self):
+ # Issue python/cpython#38179: pythonw.exe will raise an IOError after
+ # attempting to print more than 4096 bytes (it silently
+ # succeeds for the first 4096 bytes and fails with an
+ # IOError: "[Errno 9] Bad file descriptor" on the 4097th byte.
+ DETACHED_PROCESS = 0x00000008
+ command = [sys.executable, '-c',
+ 'for _ in xrange(100000): print "a", ']
+ retcode = subprocess.call(command, creationflags=DETACHED_PROCESS)
+ self.assertEqual(retcode, 0)
+
class TemporaryFileTests(unittest.TestCase):
def setUp(self): |
Does this affects Python 3? |
Python 3 is not affected: pythonw.exe sets sys.stderr to None, and print() silently discards the output in this case. |
Is it really worth leaving this open? There's no consensus after ten years and it only impacts on Python 2.7. Mark Hammond made his view plain in msg15198, which is supported by the fact that a type has yet to be allocated. |
This is still an issue for Python 2 users. Most important that pythonw.exe has a magic ability to fail silently leaving users with no means to create valid bug reports (the reason why StackOverflow questions are downvoted and erased). http://bugs.ascend4.org/print_bug_page.php?bug_id=471 The argument in msg15198 is somewhat misleading. If pythonw.exe fails because of print statement or because other issue, there is no way to report that. Anyway, this reminds me very much of mod_wsgi, with only problem that Python developers don't receive as much feedback as Graham to make the change: http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html |
I recommend against changing the code so late in the Python 2.7 release cycle. A change in behavior is too confusing. If you want to get Python 3.x style print() behavior in Python 2.7 you can have it already: from __future__ import print_function
import sys
if sys.executable.endswith("pythonw.exe"):
sys.stdout = sys.stdout = None
print("can handle sys.stdout = None just fine.") |
I agree with Christian; closing as suggested. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: