The FileIO object defined in the new io library has "name" and "mode" 
properties.  However, attempts to access either value result in an 
AttributeError exception.   The C source code in _fileio.c doesn't even 
implement a name attribute and it uses a different name for mode ("mode" 
instead of "_mode" that the property is looking for).

Broken in 2.6 and 3.0rc2.

This needs to be verified before the next rc gets out.

The attached patch is an attempt to set mode and name attributes to all
three objects in the IO stack.
For example, 
>>> f = open("foo", "U+")
>>> f.buffer.name, f.buffer.mode
('foo', 'r+')

See also the unit tests.


There is a little inconsistency that I don't know how to resolve: with
my patch, the mode does not round-trip: open(name, mode).mode is not
always equal to mode:
>>> f = open("foo", "rb")
>>> f.name, f.mode
('t', 'r')
The 'b' was removed because f is already a binary file returning bytes.

But it seems better than attaching the initial mode to the FileIO
object. Currently,
>>> io.open("foo", "Ub+", buffering=0)
_fileio._FileIO(3, 'r+')
>>> io.open("foo", "Ub+", buffering=0).mode
'Ub+'
Which is even more surprising IMO.

I'm okay with the roundtrip not being supported.  One thing I don't
quite understand is in the third test, where you're using "w+" mode and
testing f.buffer.mode and f.buffer.raw.mode is "r+".  Why is that?

r67300 (with after the fact whitespace normalization of
Lib/tests/test_io.py)

Reopening, since this causes failure in socket.makefile()

This patch addresses the makefile() function and the SocketIO class.

Here's a patch that makes FileIO accept and return 'b' in its mode string.

Since, we don't really care about round-tripping, test_gzip was fixed in
r67309.