Mailing List Archive

1 2  View All
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Mark Dickinson <dickinsm@gmail.com> 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 following script:

#!/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
running bash:

dickinsm$ ls python_source/trunk/Objects/ | (./test.py; ./test.py)
abstract.c

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)
abstract.c


I'm not 100% sure that I understand exactly what's going on here, but it's
something like the following: in the first (unbuffered) case, the
stdin.readline call of the first ./test.py only reads one line from stdin,
leaving the rest intact; so the second ./test.py also gets to output a
line. In the second case some larger amount of stdin (1024 bytes?) is
immediately slurped into the stdin buffer for the first Python process, so
the second ./test.py doesn't get anything.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Antoine Pitrou <pitrou@free.fr> 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
read1() in the FileIO class.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Antoine Pitrou <pitrou@free.fr> 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)

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Mark Dickinson <dickinsm@gmail.com> 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) matters, so if there's any
reasonable way of avoiding changing this it should probably be considered.

Though I have to admit that I'm not one of those users (I don't think I've
*ever* used the -u option outside of testing...).

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Antoine Pitrou <pitrou@free.fr> 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 always been buffered in py3k. My
original commit actually attempted to change it, and it failed (I hadn't
noticed it at first due to mis-testing on my part). The new patch is
about putting it back in buffered mode even with '-u'.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Mark Dickinson <dickinsm@gmail.com> 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 intentional design change? Or was it just an
accident/by-product of the rewritten io?

Anyway, the patch looks good to me.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Antoine Pitrou <pitrou@free.fr> 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
it was simply overlooked. Otherwise 'python3.0 -u' would have had at
least unbuffered stdout/stderr, which it didn't have.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Changes by Antoine Pitrou <pitrou@free.fr>:


----------
assignee: -> pitrou
resolution: -> accepted

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
[issue4705] python3.0 -u: unbuffered stdout [ In reply to ]
Antoine Pitrou <pitrou@free.fr> 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 <report@bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

1 2  View All