Note that the whole httplib uses this behavior -- issue 1348.
Bill
Guido van Rossum <[EMAIL PROTECTED]> 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 <[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/janssen%40parc.com
_______________________________________________
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
