On 6/5/2014 7:30 PM, Marko Rauhamaa wrote:
Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>:
"Can be replaced" by who? By the Python developers? By me? By random
library calls?
By you. sys.stdout and friends are writable. Any code you call may
have replaced them with another file-like object, and you should
honour that.
I can of course overwrite even sys and os and open and all. That hardly
merits mentioning in the API documentation.
What I'm afraid of is that the Python developers are reserving the right
to remove the buffer and detach attributes from the standard streams in
a future version.
No, not at all.
That would be terrible.
Agreed.
If it means some other module is allowed to commandeer the standard
streams, that would be bad as well.
I think that, for the most part, library modules should either open a
file given a filename from outside or read from and write to open files
handed to them from outside, but not hard-code the std streams. The
module doc should say if the file (name or object) must be text or in
particular binary.
The warning is also a hint as to how to solve a problem, such as testing
a binary filter. Assume the module reads from and writes to .buffer and
has a main function. One approach, untested:
import sys, io, unittest
from mod import main
class Binstd:
def __init(self):
self.buffer = io.BytesIO
sys.stdin = Binstd()
sys.stdout = Binstd()
sys.stdin.buffer.write('test data')
sys.stdin.buffer.seek(0)
main()
out = sys.stdout.buffer.getvalue()
# test that out is as expected for the input
# seek to 0 and truncate for more tests
Worst of all, I don't know why the caveat had to be there.
Because the streams can be replaced for a variety of good reasons, as above.
Or is it maybe because some python command line options could cause
buffer and detach not to be there? That would explain the caveat, but
still would be kinda sucky.
The doc set documents the Python command line options, as well any that
are CPython specific. It is possible that some implementation could add
one to open stdxyz in binary mode. CPython does not really need that.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
