When you've become used to writing with open("xzy", "w") as f: it's strange when it doesn't work for gzip.open or bz2.BZ2File. Or is there a reason for them not being context managers?
Thanks. The outcome of the StringIO discussion isn't clearly negative, although Guido does not see a big benefit in it. If some people are opposed to this, please stand up :) Otherwise I'll commit the patch to trunk.
I love "with ... as f:" and I want it for gzip/bz2 files! Comment about the patch: (1) the IOError message is different for the two modules: "I/O operation on closed GzipFile object" vs "I/O operation on closed file" Specify the object name in both messages or remove it from both messages. I prefer verbose error message ("I/O operation on closed BZ2File object"). (2) For bz2module, Why don't you call BZ2File_close() directly instead of the generic version PyObject_CallMethod(... "close" ...)?
> (1) the IOError message is different for the two modules: > "I/O operation on closed GzipFile object" > vs > "I/O operation on closed file" I've reused the same error message as used in other parts of each module. > (2) For bz2module, Why don't you call BZ2File_close() directly instead > of the generic version PyObject_CallMethod(... "close" ...)? Because someone may subclass BZ2File and override the close() method. I don't know if it's likely to happen, though.
Documentation needs to be updated to state that these are now context managers. This is important since they aren't in python-2.x. I'm not sure whether this should be added to the "new in python" blurbs.
