For 3.x, I think that ignoring non-string names is a reasonable fix. The docs
for io.FileIO specify that its name attribute can be either a path or an integer
file descriptor, and changing this doesn't seem to serve any purpose.

As for the case of 2.7's bogus "<fdopen>" name attribute, I'm not sure what the
best course of action is. I agree that ideally we would want to get rid of the
attribute altogether (for objects returned by fdopen), or change the semantics
to those used by FileIO in 3.x, but making that sort of change in a bugfix
release seems unwise.

One alternative would be for GzipFile to specifically check whether a file
object was returned by fdopen(), and if so ignore the fake name. I'm not sure
how this could be accomplished, though - just checking for name == "<fdopen>" is
too fragile for my liking, and I can't see any other obvious way of
distinguishing objects created by fdopen() from those created by open().

> (another quick test shows that gzip in python 3.x can't output to a BytesIO
> fileobj at all, it thinks it is readonly)

Are you sure about this? I can't reproduce the problem. Running this script:

    import gzip, io

    b = io.BytesIO()
    with gzip.GzipFile(fileobj=b, mode="w") as g:
        g.write(b"asdf ghjk")
    print(b.getvalue())
    b.seek(0)
    with gzip.GzipFile(fileobj=b, mode="r") as g:
        print(g.read())

I get the following output:

    b'\x1f\x8b\x08\x00\xe1\xa4\x14O\x02\xffK,NISH\xcf\xc8\xca\x06\x00P\xd2\x1cJ\t\x00\x00\x00'
    b'asdf ghjk'