[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Python 3.2 has some deadly infection

On 6/5/2014 7:30 PM, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python at 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.


> 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')
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