New submission from Julien Palard <julien+pyt...@palard.fr>:
Currently the curses module can raise some `_curses.error` exception directly inheriting `Exception`. This make it non-trivial for a newcomer to catch (they think they need a `from _curses import error`, or an `except Exception`, but in fact `error` is imported, in `curses/__init__.py`, in an `_curses import *`). The `curses.error` is documented, but it's not documented that `curses.setupterm` can raise it and what the user sees on the exception message is "_curses.error" not "curses.error". Questions: - Should we create a properly named curse.CurseException, inheriting from _curses.error, so people can slowly migrate to use a "properly" named exception class? - Should we document that setupterm can raise it? - Should we introduce a dedicated sphinx directive to document exceptions? I know the third question opens a whole field of work in the doc, it's only an anecdote but a student of mine pointed out yesterday that the doc is *not* telling what `int()` raises when an invalid argument is given. It's obvious for "us", but not for everybody (Yes I can teach it, yes he can just try it, but I'm not behind everyone on earth learning Python, some are learning alone, and I also want them to succeed). ---------- components: Library (Lib) messages: 360556 nosy: mdk priority: normal severity: normal status: open title: curses.setupterm can raise _curses.error type: behavior _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39433> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
