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 <abedil...@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-le...@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/DRF6EMT3QFPBVTS3S76EEMKHJDCHUHVQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/G5YXUNFGWI2HI44WZDR5K3PO3QBAZR5B/ Code of Conduct: http://python.org/psf/codeofconduct/
