| msg75337 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2008-10-30 00:07 |
| 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. |
|
|
| msg75431 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-10-31 21:37 |
| 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; |
|
|
| msg75435 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2008-11-01 01:12 |
| @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__ |
|
|
| msg75436 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2008-11-01 01:28 |
| 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. |
|
|
| msg75437 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-11-01 01:44 |
| Another patch based on Victor's patch. It adds some additional tests and exposes the internal attribute closefd. |
|
|
| msg75514 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-11-05 01:23 |
| Here is a new patch with doc and NEWS updates. |
|
|
| msg75524 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2008-11-05 19:28 |
| Small typo, conveyed to Crys_ in irc. |
|
|
| msg75526 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-11-05 19:32 |
| Applied in r67106 (py3k) The patch must be backported to 2.6 and 2.7. |
|
|
| msg75803 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2008-11-12 22:19 |
| 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". |
|
|
| msg75807 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-11-12 22:56 |
| Yes, it should. I've lefted the bug open for this very reason. |
|
|
| msg76150 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2008-11-20 23:39 |
| 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? |
|
|
| msg77019 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2008-12-05 14:34 |
| 2.6.1 is released. Should this issue be apply to 2.6.x or not? |
|
|
| msg80788 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2009-01-29 22:38 |
| 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. |
|
|