This happens with a recent py3k build:

>>> x = open(0, closefd=False)
>>> del x
C:\dev\python\py3k\lib\io.py:1461: RuntimeWarning: Trying to close 
unclosable fd!
  self.buffer.close()
C:\dev\python\py3k\lib\io.py:389: RuntimeWarning: Trying to close 
unclosable fd!
  self.close()
__main__:1: RuntimeWarning: Trying to close unclosable fd!

Also, there are no unit test for closefd.

I don't see a good 'n easy way to fix the issue. close() is called in
too many places and I don't wanna add more checks in Python code. 

This patch reduces the mass of warnings to one, but it also changes the
semantic of close() a bit. However it seems logical to set the fd
attribute of the file object to -1 (meaning closed).

Index: Modules/_fileio.c
===================================================================
--- Modules/_fileio.c   (Revision 67068)
+++ Modules/_fileio.c   (Arbeitskopie)
@@ -60,7 +60,8 @@
 static PyObject *
 fileio_close(PyFileIOObject *self)
 {
-       if (!self->closefd) {
+       if (!self->closefd && self->fd >= 0) {
+               self->fd = -1;
                if (PyErr_WarnEx(PyExc_RuntimeWarning,
                                 "Trying to close unclosable fd!", 3) < 0) {
                        return NULL;

@christian: Your patch doesn't work: if close() if called twice, the 
file is really closed :-/

Here is a new patch:
 - _FileIO.close() sets self->fd to -1 but don't show a warning anymore 
because the operation is valid: it does really close the _FileIO object
 - add two tests for two problems: read is now blocked if the file is 
closed, and the warning displayed by FileIO.__del__

christian just told me that my svn repos was old. Here is an updated 
version of my patch. I now use io.open() instead of io.BufferedReader() 
in the tests.

Another patch based on Victor's patch. It adds some additional tests and
exposes the internal attribute closefd.

Here is a new patch with doc and NEWS updates.

Small typo, conveyed to Crys_ in irc.

Applied in r67106 (py3k)

The patch must be backported to 2.6 and 2.7.

Can this change be backported to 2.6 and 2.7?
r67106 says that it "Changed semantic of close() on file objects with 
closefd=False".

Yes, it should. I've lefted the bug open for this very reason.

Backported to trunk in r67307.

But -- do we really want to backport to 2.6? This changes the semantics 
of closefd, adds a new closefd attribute...
Did the rules change for 2.6.1?

2.6.1 is released. Should this issue be apply to 2.6.x or not?

This issue has been fixed in py3k, release30-maint and trunk. I think 
that 2.6.x doesn't need this API change, so I prefer to close this 
issue. Reopen the issue if I'm wrong.