On 7/8/05, James Y Knight <foom@fuhm.net> wrote:
It is a really bad idea to codify the practice of modifying non- threadlocal global state like sys.std[in|out|err] and current directory with a context manager. A user can do it to themselves now, true, but by putting a context manager for it in the stdlib, you make it look like it'd be a local modification when it is not. I can only see confusion resulting from this. Users will inevitably try to use it like with sys.redirected_stderr(f):
Which is of course a bug -- print doesn't go to stderr. Not sure if you meant this as an illustration of a typical bug or whether you meant sys.redirect_stdout(f).
print "hello" print "there" instead of explicitly writing to f with print>> or write(). And that is just a terribly bad idea. It looks pretty, yes, but unless stdinouterr are made thread-local, it's just asking for trouble.
Boy, do you have Java (or multi-threading) on your mind. A lot of Python programs are single-threaded, and this idiom has been promoted by examples for many years; I see nothing wrong with it in single-threaded code. I sure hope the world doesn't evolve to one where most programs have to be multi-threaded to be useful! Multi-threading is such a nightmare to program that we should really look for paradigms that hide it completely rather than trying to raise programmers who will write correct multi-threaded programs naturally; the latter just ain't gonna happen. A major use case for this, BTW, is to take *existing* Python code that was written using print statements and wrap it in something that captures its output. The f.write() or print>>f solutions won't work there... -- --Guido van Rossum (home page: http://www.python.org/~guido/)