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
python3.0 -u: unbuffered stdout #48955
Comments
I like and I need an "unbuffered" standard output which was provided The problem is in initstdio() which creates files with buffering=-1 Example with py3k trunk: $ ./python
>>> import sys; sys.stdout.line_buffering
True
$ ./python |cat
>>> import sys; sys.stdout.line_buffering
False I would like line buffering when stdout is redirected to a pipe and -u Index: Python/pythonrun.c --- Python/pythonrun.c (révision 67870)
+++ Python/pythonrun.c (copie de travail)
@@ -810,7 +810,12 @@
#endif
}
else {
- if (!(std = PyFile_FromFd(fd, "<stdout>", "w", -1,
encoding,
+ int buffering;
+ if (1)
+ buffering = 1; /* line */
+ else
+ buffering = -1; /* default */
+ if (!(std = PyFile_FromFd(fd, "<stdout>", "w",
buffering, encoding,
errors, "\n", 0))) {
goto error;
} But "if (1)" have to be replaced "if -u option is used" :-) See |
Just as a note, Pydev needs the unbuffered output (or it cannot get it). As a workaround for now I'm using: but that doesn't seem right as it's accessing an internal attribute. |
Here is a patch. |
pitrou's patch changes PyFile_FromFd() behaviour for a text file Why changing PyFile_FromFd() and not io.open() directly? Note: I prefer Py_UnbufferedStdoutFlag=1 instead of Except the minor comments, I like the patch (and it has unit |
I must admit I'm a bit lazy, and changing io.open() means changing a
Well, I minimally changed the existing code. |
You're right, and PyFile_FromFd() is also a fundamental "public" API. My new patch only changes initstdio() using pitrou's code. Should we also change stdin? |
Le dimanche 28 décembre 2008 à 12:19 +0000, STINNER Victor a écrit :
Well, open() is fundamental as in part of the built-ins and used
I don't know, but "python -h" only talks about stderr/stdout. |
It seems the "name" field of the TextIOWrapper object isn't set in |
The manpage of Python2 is clear: -u Force stdin, stdout and stderr to be totally unbuffered. stdin is also unbuffered.
It used only used for buffered output. Without the patch, New patch:
Note: there is no test for unbuffered input because I don't know how |
Attached: quick and dirty test to check if the standard input is About the wrong name, I opened a separated issue: bpo-4762, |
Instead of importing IO each time in create_stdio, maybe you should just |
create_stdio() uses io.open() but also io.TextIOWrapper. Since io |
If |
Updated patch: clear raw on error Question: Should we use line_buffering in unbuffered mode? |
Committed in r68451. Thanks! |
Reopening, since sys.stdin is actually broken in unbuffered mode: $ ./python -u
Python 3.1a0 (py3k:68756, Jan 19 2009, 01:17:26)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.read(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/antoine/py3k/__svn__/Lib/io.py", line 1739, in read
eof = not self._read_chunk()
File "/home/antoine/py3k/__svn__/Lib/io.py", line 1565, in _read_chunk
input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'FileIO' object has no attribute 'read1'
>>> What I propose is that stdin be always opened in buffered mode (even |
Here is a patch. |
Unless I'm misunderstanding you (quite likely), I think one *can* get #!/usr/bin/python -u
import sys
print sys.stdin.readline() and name it test.py, I get the following result in an OS X Terminal dickinsm$ ls python_source/trunk/Objects/ | (./test.py; ./test.py) boolobject.c Whereas if I remove the '-u' from the shebang line I just get: dickinsm$ ls python_source/trunk/Objects/ | (./test.py; ./test.py) I'm not 100% sure that I understand exactly what's going on here, but it's |
[...] I hadn't thought of such situations :-/ So the question is whether it is really useful to enforce unbuffered |
Thinking about it, TextIOWrapper has its own input buffering (the (and disabling TextIOWrapper's internal buffering would be a bad idea |
Hard to say. It seems at least possible that there are Python users for Though I have to admit that I'm not one of those users (I don't think I've |
It's not about changing it, stdin has always been buffered in py3k. My |
Sorry: I should have been clearer. It's the change from 2.x to 3.x that So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does not; I'm Anyway, the patch looks good to me. |
I'm not sure (I didn't write the new io in the first place) but I'd say |
Committed and applied a small fix to the test so that it passes in debug |
Can I confirm this is still in the trunk? I have 3.3.2 and am suffering from the fact that |
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: