[Python-Dev] Patch 595601

[Guido van Rossum]

> [Greg Ewing]
> > I don't think raising an exception is the right thing to do here. The
> > closing thread hasn't really done anything wrong, it just happened to
> > do the close at a moment that was inconvenient to another thread.

I disagree that the thread has done nothing wrong: if one thread is
closing a file that another thread is still reading, the whole
application is buggy, and if raising an exception in close() is the
most expedient way to tell the application that it is buggy, that's
fine with me.  The application needs to be fixed anyway.

[Tim]
> At the level of C streams, it's engaging in undefined behavior.  That's
> always wrong, except when Python explicitly decides to provide semantics
> beyond what C and POSIX specify.  As far as POSIX is concerned, what happens
> when you close a stream while a read or write is in progress is undefined.

In such cases, Python ought to provide specified behavior beyond POSIX
that at least guarantees that a Python program won't core dump or
otherwise get into an undefined or unusable state as a result of
engaging in such behavior.

BTW, I try to have a practical attitude about behavior that standards
don't define.  I care about undefined behavior that is actually
observed on some platform we (try to) support.  For example, what
happens when int arithmetic overflows is undefined by the C std, but
we don't guard against this because in practice it is harmless enough.
OTOH if closing a file that's being read by another thread can cause
crashes on some platforms, Python should guard against this.

We don't have the resources to guard against everything that standards
call undefined; and there are lots of things that you want to do that
can only be done by using undefined things: platforms often violate
standards, and/or define things that the standard leaves undefined.

As Tim knows, 100% standard-compliant life would be very dull.

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