[issue4705] python3.0 -u: unbuffered stdout

Joe Borg added the comment: Can I confirm this is still in the trunk? I have 3.3.2 and am suffering from the fact that `-u` isn't setting stdin to unbuffered. I'm have to run a flush every command, which is awful. -- nosy: +Joe.Borg, georg.brandl versions: +Python 3.2, Python 3.3 __

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Committed and applied a small fix to the test so that it passes in debug mode (r68977, r68981, r68982). Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : -- assignee: -> pitrou resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: > So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does not; > I'm wondering: was this an intentional design change? Or was it just > an accident/by-product of the rewritten io? I'm not sure (I didn't write the new io in the first place) but I'd say

[issue4705] python3.0 -u: unbuffered stdout

Mark Dickinson added the comment: > It's not about changing it, stdin has always been buffered in py3k. Sorry: I should have been clearer. It's the change from 2.x to 3.x that interests me. So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does not; I'm wondering: was this an int

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: > Hard to say. It seems at least possible that there are Python users for > whom stdin being unbuffered (with -u) matters, so if there's any > reasonable way of avoiding changing this it should probably be considered. It's not about changing it, stdin has al

[issue4705] python3.0 -u: unbuffered stdout

Mark Dickinson added the comment: > So the question is whether it is really useful to enforce unbuffered > stdin with the '-u' option (or your example is simply too borderline). Hard to say. It seems at least possible that there are Python users for whom stdin being unbuffered (with -u) matte

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Thinking about it, TextIOWrapper has its own input buffering (the `decoded_chars` attribute), so your use case would probably not be satisfied. (and disabling TextIOWrapper's internal buffering would be a bad idea since it would make it horribly slow)

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: [...] I hadn't thought of such situations :-/ So the question is whether it is really useful to enforce unbuffered stdin with the '-u' option (or your example is simply too borderline). If so, the patch will have to be replaced with another one implementing re

[issue4705] python3.0 -u: unbuffered stdout

Mark Dickinson added the comment: > since I don't see how the behaviour can differ for a read-only > non-seekable stream. Unless I'm misunderstanding you (quite likely), I think one *can* get different results with buffered and unbuffered stdin. For example, on my machine, if I create the foll

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12657/unbufferedstdout-5.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12556/unbufferedstdout-4.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12479/test_stdin.py ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12475/unbufferedstdout.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : -- priority: high -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Here is a patch. Added file: http://bugs.python.org/file12798/unbuffered-stdin.patch ___ Python tracker ___

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: 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) T

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Committed in r68451. Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___

[issue4705] python3.0 -u: unbuffered stdout

Changes by Antoine Pitrou : -- resolution: -> accepted stage: patch review -> commit review versions: +Python 3.1 ___ Python tracker ___ _

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: Updated patch: clear raw on error + if (!Py_UnbufferedStdioFlag) + Py_XDECREF(raw); Question: Should we use line_buffering in unbuffered mode? Added file: http://bugs.python.org/file12657/unbufferedstdout-5.patch __

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: If `PyObject_SetAttrString(raw, "_name", text)` fails, a reference to raw is leaked. Other than that, the patch looks good. ___ Python tracker ___ __

[issue4705] python3.0 -u: unbuffered stdout

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12478/unbufferedstdout-3.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: > Instead of importing IO each time in create_stdio, > maybe you should just pass io.open to create_stdio create_stdio() uses io.open() but also io.TextIOWrapper. Since io module is already imported in initstdio(), I updated the patch to just pass the pointe

[issue4705] python3.0 -u: unbuffered stdout

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12477/unbufferedstdout-2.patch ___ Python tracker ___ ___ Python-bugs-list

[issue4705] python3.0 -u: unbuffered stdout

Benjamin Peterson added the comment: Instead of importing IO each time in create_stdio, maybe you should just pass io.open to create_stdio. -- nosy: +benjamin.peterson ___ Python tracker ___

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: Attached: quick and dirty test to check if the standard input is buffered or not. My short test program works with python2.5 and py3k trunk without the -u command line option. So changing sys.stdin buffer is not really important. About the wrong name, I open

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: >> Should we also change stdin? > I don't know, but "python -h" only talks about stderr/stdout. The manpage of Python2 is clear: -u Force stdin, stdout and stderr to be totally unbuffered. stdin is also unbuffered. > It seems the "name" field of the T

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: It seems the "name" field of the TextIOWrapper object isn't set in create_stdio() (the "char *name" parameter isn't used). Otherwise, the patch looks good. ___ Python tracker __

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Le dimanche 28 décembre 2008 à 12:19 +, STINNER Victor a écrit : > STINNER Victor added the comment: > > > > Why changing PyFile_FromFd() and not io.open() directly? > > > > I must admit I'm a bit lazy, and changing io.open() means changing > > a fundamen

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: > > Why changing PyFile_FromFd() and not io.open() directly? > > I must admit I'm a bit lazy, and changing io.open() means changing > a fundamental public API, as Guido said on python-dev, so > more discussion and some parts of the patches delayed to 3.1. You

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: > pitrou's patch changes PyFile_FromFd() behaviour for a text file > opened with buffering=0: > /* As a convenience, when buffering == 0 on a text file, we > open the underlying binary stream in unbuffered mode and > wrap it with a text stream in li

[issue4705] python3.0 -u: unbuffered stdout

STINNER Victor added the comment: pitrou's patch changes PyFile_FromFd() behaviour for a text file opened with buffering=0: /* As a convenience, when buffering == 0 on a text file, we open the underlying binary stream in unbuffered mode and wrap it with a text stream in line-buffere

[issue4705] python3.0 -u: unbuffered stdout

Antoine Pitrou added the comment: Here is a patch. -- keywords: +patch nosy: +pitrou priority: -> high stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file12475/unbufferedstdout.patch ___ Python tracker

[issue4705] python3.0 -u: unbuffered stdout

Fabio Zadrozny added the comment: Just as a note, Pydev needs the unbuffered output (or it cannot get it). This has been brought up in the python-dev list: http://mail.python.org/pipermail/python-dev/2008-December/084436.html As a workaround for now I'm using: sys.stdout._line_buffering = True,

[issue4705] python3.0 -u: unbuffered stdout

New submission from STINNER Victor : I like and I need an "unbuffered" standard output which was provided by -u command line option (or PYTHONUNBUFFERED environment variable). Current status of -u option in Python3: the option exists and change the buffer size (disable buffering) of the stdin,