[Python-3000] close() on open(fd, closefd=False)

[Guido van Rossum]

Are you sure? I thought that was different -- httplib depends on the
reference count semantics of socket objects. The closefd behavior that
Christian is describing here is part of the (new in 2.6 and 3.0) io.py
module.

On Mon, Nov 3, 2008 at 7:25 PM, Bill Janssen <janssen at parc.com> wrote:
> Note that the whole httplib uses this behavior -- issue 1348.
>
> Bill
>
> Guido van Rossum <guido at python.org> wrote:
>
>> 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 <lists at cheimes.de>:
>> > 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 at 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 at python.org
>> http://mail.python.org/mailman/listinfo/python-3000
>> Unsubscribe: http://mail.python.org/mailman/options/python-3000/janssen%40parc.com
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)