I see no problem in fixing this in 3.0 and 2.6.1. The current behavior
is a bug and I see no reason to expect that users would depend on it.
Sure, it might occasionally mask a bug elsewhere in their code -- but
given how esoteric this whole issue is I think its fine to consider
this simply a bug and fix it.
2008/11/2 Christian Heimes <[EMAIL PROTECTED]>:
> Martin v. Löwis wrote:
>>
>> However, this is the documented behavior:
>>
>> "the underlying file descriptor will be kept open when the file is closed."
>>
>> and, for close
>>
>> "Flush and close this stream."
>>
>> It would help if the documentation of close would read
>>
>> "Flush and close this stream. This method has no effect if the file is
>> already closed, or if closefd was False when the file object was created."
>
> I would use a slightly different wording
>
> "Flush and close this stream. This method has no effect if the file is
> already closed. Once the file is closed, any operation on the file (e.g.
> reading or writing) will fail. Close doesn't close the internal file
> descriptor if closefd was False when the file object was created."
>
> In my opinion close() should render the file *object* disabled in all cases.
> closefd should just leave the file *descriptor* open, not the file *object*.
>
>> It might be useful if closefd attribute could be reflected, so that
>> applications that know about it and really want to close the file
>> still can do that.
>
> Agreed! My latest patch adds a read only attribute closefd.
>
>> Also, is it really the case that close has no effect if closefd
>> was given? ISTM that it will still flush the file, for a
>> _BufferedIOMixin. This should systematically be clarified: it
>> should either always flush, or never (although "always flush"
>> seems more useful).
>
> I haven't looked at the code in the io yet. Our discussion was mostly about
> the _fileio C extension. To clarify the issue with an example
>
>>>> out = open(1, "w", closefd=False)
>>>> out.write("example\n")
> example
> 8
>>>> out.close()
> /usr/local/lib/python3.0/io.py:1461: RuntimeWarning: Trying to close
> unclosable fd!
> self.buffer.close()
>>>> out.write("example\n")
> example
> 8
>
> I think the second out.write() call should raise an exception instead of
> writing the string to the fd 1.
>
>> Also, why does the _BufferedIOMixin discard exceptions from flush?
>> Errors should never pass silently.
>
> Ack!
>
>> Also, why does the FileIO.close first invoke _FileIO.close, then
>> RawIOBase.close? IIUC, FileIO.close will close the file handle,
>> yet RawIOBase will attempt to flush afterwards.
>
> Apparently the io module hasn't been reviewed for its massive usage of close.
> :/
>
> Christian
> _______________________________________________
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
