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?

Here is a patch for the trunk. I'm waiting for the opinion other
developers before deciding to commit or no.

Here's the StringIO discussion: #1286

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.

Committed in trunk and py3k. Thanks!