First, let me say I like Giampaolo's TimeoutExpired *much* better as the name for this kind of exception!  But that ship has sailed.

I don't understand Giampaolo's comment.  If I understand the claim correctly, the problem is that people who should be catching some application-specific exception may be misled into catching TimeoutError instead, or into trying to get application-specific attributes from TimeoutError.  But that ship sailed with the creation of TimeoutError.  (We have a whole fleet sailing with this exception.)  Unless Giampaolo is proposing to deprecate TimeoutError?  I'm sympathetic ;-), but deprecation is a PITA and takes forever.

If we're not going to deprecate, it seems to me that it's much more developer-friendly to catch ETIME with TimeoutError, as that seems very likely to be the expected behavior.  It's true that even if Giampaolo changes TimeoutExpired to subclass TimeoutError, generic TimeoutError won't have .seconds.  But if you catch a TimeoutExpired with TimeoutError, that instance *will* have .seconds, and if you try to get .seconds on generic TimeoutError, you'll get a different uncaught exception (AttributeError vs. TimeoutError), but that TimeoutError wouldn't have been handled by catching TimeoutExpired.

I agree with Eric that people who were distinguishing OSError with .errno=ETIME from TimeoutError might be at risk, but I wouldn't do that: if I were going to be distinguishing particular OSErrors on the basis of errno (other than in "Unexpected OSError (errno = %d)" reporting style), I'd just catch OSError and do that.  On the other hand, I might expect TimeoutError to catch ETIME.  And Giampaolo says he's never seen either.  I suppose the author of psutil would be as likely as anyone to have seen it!

On net (unless we go the deprecation route) it seems that the convenience and "intuition" of adding ETIME to TimeoutError outweighs that risk.

I wish there were somebody who was there at the creation of ETIME!