[Python-Dev] Destructors and Closing of File Objects

Antoine Pitrou solipsis at pitrou.net
Mon Apr 29 18:02:23 CEST 2013

Le Mon, 29 Apr 2013 16:42:38 +0200,
Armin Rigo <arigo at tunes.org> a écrit :
> Hi Nikolaus,
> On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath <Nikolaus at rath.org>
> wrote:
> > It's indeed very informative, but it doesn't fully address the
> > question because of the _pyio module which certainly can't use any
> > custom C code. Does that mean that when I'm using x =
> > _pyio.BufferedWriter(), I could loose data in the write buffer when
> > the interpreter exits without me calling x.close(), but when using
> > x = io.BufferedWriter(), the buffer is guaranteed to get flushed?
> I actually described the behavior of CPython 2 while not realizing
> that CPython 3 silently dropped this guarantee.

It is dropped in the case of reference cycles, since there's no general
way to decide in which order the tp_clear calls have to be done.
Thus in the following layered situation: a TextIOWrapper on top of a
BufferedWriter on top of a FileIO, if BufferedWriter.tp_clear is called
first, it will flush and then close itself, closing the FileIO at the
same time, and when TextIOWrapper.tp_clear will be called it will be
too late to flush its own buffer.

(I have to investigate a bit to confirm it is what happens)

I will try to think of a scheme to make flushing more reliable, but
nothing springs to my mind right now.

Note that the issue of how reference cycles involving globals are
collected at interpreter shutdown is an orthogonal one, as pointed out
in http://bugs.python.org/issue17852.



More information about the Python-Dev mailing list