Steven D'Aprano writes:
A closed file is not *invalid*, it is just closed.
I think it's not very useful to focus on the individual words used here. I believe that Steve J's idea here is related to the fact that an object is a namespace and an environment. So the operation is not "read from specified file", it's "read as appropriate in the specified environment" (duck-typing), so the state of the environment of the call (which is the implicit argument "self") is invalid. I myself would argue it's not that the environment is in an invalid state for reading, but that reading is an invalid operation on a closed file. I note that XEmacs Lisp's docstring for the error function says: `invalid-operation' refers to all cases where code is trying to do something that's disallowed, or when an error occurred during an operation. (These two concepts are merged because there's no clear distinction between them.) I want to emphasize the remark in parentheses. It's frequently *very* difficult to make distinctions that will be clear to all users of the API, or even to all API users named "Steve". :-) In my personal opinion, the XEmacs Lisp hierarchy does a good job of specifying a hierarchy that lends itself to clear distinctions. YMMV on whether that hierarchy is a good one, but I think the point is important: there are no absolutes here, rather the quality of a distinction is relative to the rest of the hierarchy, it depends on how well it fits in. Bottom line: let's focus the argument on (1) where in the Python exception hierarchy the new builtin exception would go, and (2) per Paul Moore, if it could be used in the interpreter (I will add, or in a variety of stdlib modules), and where.