classification
Title: open(0, closefd=False) prints 3 warnings
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: amaury.forgeotdarc, barry, christian.heimes, haypo
Priority: high Keywords: patch

Created on 2008-10-30 00:08 by amaury.forgeotdarc, last changed 2009-01-29 22:38 by haypo. This issue is now closed.

Files
File name Uploaded Description Edit
fileio_closefd-2.patch haypo, 2008-11-01 01:28
fileio_closefd3.patch christian.heimes, 2008-11-01 01:44
fileio_closefd4.patch christian.heimes, 2008-11-05 01:23
Messages (13)
msg75337 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) 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) * (Python committer) 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 (haypo) * (Python committer) 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 (haypo) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2008-11-05 01:23
Here is a new patch with doc and NEWS updates.
msg75524 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2008-11-05 19:28
Small typo, conveyed to Crys_ in irc.
msg75526 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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 (haypo) * (Python committer) 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 (haypo) * (Python committer) 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.
History
Date User Action Args
2009-01-29 22:38:45hayposetstatus: open -> closed
messages: + msg80788
2008-12-05 14:34:16hayposetmessages: + msg77019
2008-11-20 23:39:39amaury.forgeotdarcsetmessages: + msg76150
2008-11-12 22:56:48christian.heimessetmessages: + msg75807
2008-11-12 22:19:46amaury.forgeotdarcsetmessages: + msg75803
2008-11-05 19:33:45christian.heimessetpriority: release blocker -> high
versions: + Python 2.6, Python 2.7, - Python 3.0
2008-11-05 19:32:13christian.heimessettype: behavior
resolution: accepted -> fixed
messages: + msg75526
assignee: christian.heimes
2008-11-05 19:28:01barrysetresolution: accepted
messages: + msg75524
nosy: + barry
2008-11-05 01:23:11christian.heimessetfiles: + fileio_closefd4.patch
messages: + msg75514
2008-11-01 01:44:58christian.heimessetfiles: + fileio_closefd3.patch
messages: + msg75437
2008-11-01 01:28:22hayposetfiles: - fileio_closefd.patch
2008-11-01 01:28:12hayposetfiles: + fileio_closefd-2.patch
messages: + msg75436
2008-11-01 01:12:22hayposetfiles: + fileio_closefd.patch
keywords: + patch
messages: + msg75435
nosy: + haypo
2008-10-31 21:37:41christian.heimessetpriority: critical -> release blocker
nosy: + christian.heimes
messages: + msg75431
2008-10-30 00:08:00amaury.forgeotdarccreate