[Skip Montanaro]
Isn't this a case of "so don't do that"?
I think so, but it's apparently debatable (since people at Zope Corp are debating it <wink>), and it doesn't excuse Python from segfaulting even if so.
I've never encountered this before, but then I don't close files in one thread while another holds a reference.
There's no problem with closing a shared file; the problem can arise only if one thread is trying to "do something" with a file at the same time another thread is trying to close that file.
Would it be reasonable to raise an error or warning if a file's close() method was called when the reference count was greater than 1?
I don't think so. Shane Hathaway sketched an approach adding (in effect) an "in use" count to the FILE* contained by a Python file object. That count would be incremented and decremented, under protection of the GIL, around pieces of implementation code that passed on the FILE*. *Then* it would make sense to raise an exception if a close() call occurred while that count was above its initial value. This count is independent of how many references there may be to the Python file object.