[Python-Dev] Patch 595601 (original) (raw)

Guido van Rossum guido@python.org
Tue, 24 Jun 2003 04:06:26 -0400

[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/)