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!

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.