Re: [Python-Dev] Can't have unbuffered text I/O in Python 3.0?
On Dec 19, 2008 2:20pm, Fabio Zadrozny <fabiofz@gmail.com> wrote:
You're right, thanks (guess I'll use that option then).
Now, is it a bug that Python 3.0 doesn't run unbuffered when
specifying -u or PYTHONUNBUFFERED, or was this support dropped?
Well, ``python -h`` still lists it. That means either the output for -h needs to be fixed or the feature needs to be supported. -Brett
Well, ``python -h`` still lists it.
Precisely, it says: -u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x see man page for details on internal buffering relating to '-u' Note the "binary". And indeed: ./python -u Python 3.1a0 (py3k:67839M, Dec 18 2008, 17:56:54) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.stdout.buffer.write(b"y") y1
I don't know what it would take to enable unbuffered text IO while keeping the current TextIOWrapper implementation... Regards Antoine.
Fror truly unbuffered text output you'd have to make changes to the io.TextIOWrapper class to flush after each write() call. That's an API change -- the constructor currently has a line_buffering option but no option for completely unbuffered mode. It would also require some changes to io.open() which currently rejects buffering=0 in text mode. All that suggests that it should wait until 3.1. However it might make sense to at least turn on line buffering when -u or PYTHONUNBUFFERED is given; that doesn't require API changes and so can be considered a bug fix. --Guido van Rossum (home page: http://www.python.org/~guido/) On Fri, Dec 19, 2008 at 2:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Well, ``python -h`` still lists it.
Precisely, it says:
-u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x see man page for details on internal buffering relating to '-u'
Note the "binary". And indeed:
./python -u Python 3.1a0 (py3k:67839M, Dec 18 2008, 17:56:54) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.stdout.buffer.write(b"y") y1
I don't know what it would take to enable unbuffered text IO while keeping the current TextIOWrapper implementation...
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
It appears that this bug was already reported: http://bugs.python.org/issue4705 Any chance that it gets in the next 3.0.x bugfix release? Just as a note, if I do: sys.stdout._line_buffering = True, it also works, but doesn't seem right as it's accessing an internal attribute. Note 2: the solution that said to pass 'wb' does not work, because I need the output as text and not binary or text becomes garbled when it's not ascii. Thanks, Fabio On Fri, Dec 19, 2008 at 9:03 PM, Guido van Rossum <guido@python.org> wrote:
Fror truly unbuffered text output you'd have to make changes to the io.TextIOWrapper class to flush after each write() call. That's an API change -- the constructor currently has a line_buffering option but no option for completely unbuffered mode. It would also require some changes to io.open() which currently rejects buffering=0 in text mode. All that suggests that it should wait until 3.1.
However it might make sense to at least turn on line buffering when -u or PYTHONUNBUFFERED is given; that doesn't require API changes and so can be considered a bug fix.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Dec 19, 2008 at 2:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Well, ``python -h`` still lists it.
Precisely, it says:
-u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x see man page for details on internal buffering relating to '-u'
Note the "binary". And indeed:
./python -u Python 3.1a0 (py3k:67839M, Dec 18 2008, 17:56:54) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.stdout.buffer.write(b"y") y1
I don't know what it would take to enable unbuffered text IO while keeping the current TextIOWrapper implementation...
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fabiofz%40gmail.com
On Sat, Dec 20, 2008 at 13:45, Fabio Zadrozny <fabiofz@gmail.com> wrote:
It appears that this bug was already reported: http://bugs.python.org/issue4705
Any chance that it gets in the next 3.0.x bugfix release?
Just as a note, if I do: sys.stdout._line_buffering = True, it also works, but doesn't seem right as it's accessing an internal attribute.
Note 2: the solution that said to pass 'wb' does not work, because I need the output as text and not binary or text becomes garbled when it's not ascii.
Can't you decode the bytes after you receive them? -Brett
Thanks,
Fabio
On Fri, Dec 19, 2008 at 9:03 PM, Guido van Rossum <guido@python.org> wrote:
Fror truly unbuffered text output you'd have to make changes to the io.TextIOWrapper class to flush after each write() call. That's an API change -- the constructor currently has a line_buffering option but no option for completely unbuffered mode. It would also require some changes to io.open() which currently rejects buffering=0 in text mode. All that suggests that it should wait until 3.1.
However it might make sense to at least turn on line buffering when -u or PYTHONUNBUFFERED is given; that doesn't require API changes and so can be considered a bug fix.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Dec 19, 2008 at 2:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Well, ``python -h`` still lists it.
Precisely, it says:
-u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x see man page for details on internal buffering relating to '-u'
Note the "binary". And indeed:
./python -u Python 3.1a0 (py3k:67839M, Dec 18 2008, 17:56:54) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.stdout.buffer.write(b"y") y1
I don't know what it would take to enable unbuffered text IO while keeping the current TextIOWrapper implementation...
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fabiofz%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
It appears that this bug was already reported: http://bugs.python.org/issue4705
Any chance that it gets in the next 3.0.x bugfix release?
Just as a note, if I do: sys.stdout._line_buffering = True, it also works, but doesn't seem right as it's accessing an internal attribute.
Note 2: the solution that said to pass 'wb' does not work, because I need the output as text and not binary or text becomes garbled when it's not ascii.
Can't you decode the bytes after you receive them?
Well, in short, no (long answer is that I probably could if I spent a long time doing my own console instead of relying on what's already done and working in Eclipse for all the current available languages it supports, but that just doesn't seem right). Also, it's seems easily solvable (enabling line buffering for the python streams when -u is passed) in the Python side... My current workaround is doing that on a custom site-initialization when a Python 3 interpreter is found, but I find that this is not the right way for doing it, and it really feels like a Python bug. -- Fabio
participants (5)
-
Antoine Pitrou -
bcannon＠gmail.com -
Brett Cannon -
Fabio Zadrozny -
Guido van Rossum