But it doesn't seem to work. When I check the above example with mypy I still get errors:
tmp.py contains:

import gzip, shutil
shutil.copyfileobj(gzip.GzipFile("/tmp/test.txt.gz", "r"),
                   gzip.GzipFile("/tmp/test.txt.gz", "w"))

and mypy -2 __tmp__.py (using the latest master) gives

__tmp__.py:2: error: Cannot instantiate abstract class 'GzipFile' with abstract attributes '__enter__', '__exit__', ... and 'writelines' (6 methods suppressed)
__tmp__.py:3: error: Cannot instantiate abstract class 'GzipFile' with abstract attributes '__enter__', '__exit__', ... and 'writelines' (6 methods suppressed)

That's a different error than before but still an error. :-(

(It's actually worse because you get this error on any instantiation of GzipFile.)

Oops, missed this yesterday. Right, mypy's version of typing.pyi (a.k.a. the typeshed version) declares most methods in IO abstract. Maybe that's correct in cases where you inherit from IO in your .py, but in .pyi, it seems to cause trouble. Hopefully, with PEP 544, explicit subclassing of IO won't be needed anymore, and then maybe we can just make the methods in typing.pyi concrete.

In any case, sorry for breaking this! I was testing with pytype's typing.pyi (https://github.com/google/pytype/blob/master/pytype/pytd/builtins/typing.pytd) which looks slightly different.

Well, the IO class in typing.py (i.e. at runtime) really is abstract, but the various classes defined in io and _io (at runtime) are concrete, and I think typeshed should follow -- IO in typing.pyi should be abstract but the classes in io.pyi and _io.pyi should be concrete. Which is what my PR already did. I just don't think there's a future action item.