the docs (http://docs.python.org/3.x/library/io.html#io.FileIO) do not document closefd, and AFAICT it isn't possible to tell if closefd is set after the object is created. Specifically it does not show up in the repr().

>>> import sys
>>> sys.stdout
<_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
>>> sys.stdout.buffer
<_io.BufferedWriter name='<stdout>'>
>>> sys.stdout.buffer.raw
<_io.FileIO name='<stdout>' mode='wb'>

If one wants to reopen sys.std in non-buffered mode, the right thing to do according to a recent thread on python-ideas is to use fdopen - e.g.

mystream = io.open(sys.stdout.fileno(), 'wt', 0) 
but this will set closefd to True in the new object, which results in hilarity when it gets garbage collected. And you cannot tell or compare that to the original stdout because of the lack of exposure of this attribute and it's implications. (Does it close the fd on __del__? After each operation? On close() being called on the FileIO object?)

From the 3.5 docs.

io.open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)
This is an alias for the builtin open() function.

There is a description for closefd at the open() function link. So how about adding to the sentence above " where all the above parameters are described" ?

Its more than just a docs issue - "AFAICT it isn't possible to tell if closefd is set after the object is created."

The presence of the parameter in the signature is there, but it isn't documented *where the bulk of the FileIO parameters are* - there are docs for mode for instance. Why would we force users to follow breadcrumbs for one parameter but not other ones?

Oh - the the 'open' function docs are fine - they are just a pointer. I was specifically referring to the class docs around line 513 of Doc/library/io.rst.

Attached is a patch that changes repr to show this attribute and extends the docs to document this as part of FileIO.

I think the information from the following line of the 'open' docs should be added to the doc patch:

"If a filename is given closefd has no effect and must be True (the default)."

Otherwise it looks fine to me.

New changeset a1500e4a159a by Robert Collins in branch 'default':
Issue bpo-17401: document closefd in io.FileIO docs and add to repr
https://hg.python.org/cpython/rev/a1500e4a159a

FileIO repr now looks confusing:

>>> sys.stdout.buffer.raw
<_io.FileIO name='<stdout>' mode='wb' closefd='0'>

The closefd attribute is not a string '0' or '1', it is boolean value True or False. Here is a patch which fixes a repr.

And I think that documentation part of the patch should be backported.

Yeah thats nicer. I'll apply that later unless you can.

May be include closefd in the repr only when it is False? By default closefd is True and in common case the repr will be more compact.

Showing it only when False would have higher cognitive load. Showing it always is simple and clear.

New changeset fd80195b920f by Serhiy Storchaka in branch 'default':
Issue bpo-17401: Output the closefd attribute as boolean.
https://hg.python.org/cpython/rev/fd80195b920f

Committed the first patch (showing closefd always) with additional test from second path.

Arfrever have suggested on IRC to backport documentation part of the patch to 3.4.