That would break huge amounts of existing code. While better names might have been nice from the start, improving the naming is nowhere near enough benefit to justify such a disruptive change at this point in Python's development. Paul On Fri, 24 Jun 2022 at 22:47, abed...@gmail.com <abedillon@gmail.com> wrote:
I was reading some of Kevlin Henney's views on naming conventions, and I realized that, of the 65 classes that make up Python's built-in exceptions, only 8 (by my count) satisfy Henney's pretty basic concept of a good Exception name:
The name should represent whatever the problem is, and should do so directly and specifically. To add Exception to the end is either redundant — so remove it — or an indication of a poor name — so rename it.
Those are: SystemExit, KeyboardInterrupt, GeneratorExit, Exception, StopIteration, StopAsyncIteration, Warning, and BaseException (though Henney also discourages the use of "Base" in a base-class's name)
I'm sure there are others throughout the standard library too.
I always caution novice programmers to err on the side of pragmatism over dogmatic adherence to "sacred truths". To that end:
1) I realize changing built-in exception names would break backwards compatibility and probably isn't worth doing. This post is more intended as food for thought going forward and to bring more attention to Kevlin Henney's ideas.
2) I think many of the built-in exceptions are actually fine, particularly ones that represent a broad class of more specific exceptions like OSError. I don't think OSError has a specific enough name to be raised on its own (perhaps it should be abstract or otherwise not directly instantiable?), but catching error categories can be pretty helpful even if they don't lend themselves to explicit names.
I would suggest a more ideal naming scheme would be something like the following:
BaseException -> Exception # The text for GeneratorExit seems to indicate that in Python, an Error is considered a subclass of an Exception, so this naming seems more appropriate though it contradicts other views on the distinction between Exception and Error.
SystemExit KeyboardInterrupt -> UserInterrupt #This is supposed to capture a user-initiated exit, whether it came from a keyboard or a magic wand is generally much less relevant GeneratorExit Exception -> Error
StopIteration StopAsyncIteration ArithmeticError
FloatingPointError -> Not used, get rid of it? OverflowError -> Overflow ZeroDivisionError -> ZeroDivision or Undefined
AssertionError -> Contradiction or AssertionViolation AttributeError
+ AttributeNotFound or AttributeUnavailable + AttributeUnassignable
BufferError
<specific errors>
EOFError -> EndOfFile ImportError
ModuleNotFoundError -> ModuleNotFound
LookupError
IndexError -> IndexOutOfBounds KeyError -> KeyNotFound
MemoryError -> OutOfMemory NameError -> InvalidName (Not needed?)
UnboundLocalError -> UnboundLocal
OSError
BlockingIOError -> BlockingIO ChildProcessError -> ChildProcessFailed ConnectionError
BrokenPipeError -> BrokenPipe ConnectionAbortedError -> ConnectionAborted ConnectionRefusedError -> ConnectionRefused ConnectionResetError -> ConnectionReset
FileExistsError -> FileAlreadyExists FileNotFoundError -> FileNotFound InterruptedError -> Interrupted IsADirectoryError -> NotAFile NotADirectoryError -> NotADirectory PermissionError -> PermissionDenied ProcessLookupError -> ProcessNotFound TimeoutError -> Timeout
ReferenceError -> ReferentCollected? RuntimeError
NotImplementedError -> NotImplemented RecursionError -> MaxRecursionDepthExceeded or RecursionOverflow
SyntaxError
IndentationError
TabError -> InconsistentIndentation
SystemError -> SystemFailure TypeError -> IncompatibleType ValueError
UnicodeError
UnicodeDecodeError UnicodeEncodeError UnicodeTranslateError
Warning # Should this be under Error?
DeprecationWarning -> Deprecated PendingDeprecationWarning -> Obsolete RuntimeWarning SyntaxWarning UserWarning FutureWarning ImportWarning UnicodeWarning BytesWarning EncodingWarning ResourceWarning
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DRF6EM... Code of Conduct: http://python.org/psf/codeofconduct/