On Aug 8, 2019, at 08:52, Ryan Fox <r...@rcfox.ca> wrote:
>
> >>> class MyException(Exception):
> ... def __init__(self, action, context):
> ... super().__init__(f'Bad thing happened during {action} in
> {context}')
> >>> raise MyException(current_action, current_context)
...
> Version 2 looks simple enough to do, but all of the repetitious boilerplate
> adds up when several exception types need to be defined. (And it's even worse
> when you want all of your code to include typing annotations.) Most people
> don't bother.
>
> My proposal is a new exception class as the preferred base for user-defined
> exceptions:
>
> >>> class MyException(ExceptionTemplate):
> ... message = 'Bad thing happened during {action} in {context}'
> >>> raise MyException(action=current_action, context=current_context)
Does this really save boilerplate?
Your magic template has apparently turned positional-or-keyword parameters into
keyword-only. This means that every exception class that you’d normally
construct with positional args today (which apparently includes even your
example, since that’s what you did in version 1 and 2) now requires keyword
boilerplate on every line where you construct one. And, since you generally
construct and use a class many times, but only define it once, that’s adding a
lot more boilerplate than it’s saving.
Also, even in the definition, while you are saving one line, you’re doing it by
replacing a standard idiom used all over Python that has an obvious meaning,
which nobody ever forgets how to write, with magic involving a special name
that’s unlike anything else in the stdlib, which many people will forget how to
write, forcing them to look up the docs or find an example whenever they add
the first new exception to a new module.
Also, this doesn’t fill in the exception’s stored args. Is there a way to fix
that without requiring more boilerplate? Remember, stored args are positional,
not keywords. So, even if you can come up with some magic (e.g., parsing the
format string to sort the keywords in the order of first appearance), that only
helps the interpreter, not a human reader who sees exc.args[2] in an except
clause for an exception created with three keyword args and has to guess which
one is #2. Without explicitly listing the args in order somewhere, how do you
solve that? And is there a way to list the named args of a function in order
that’s less boilerplate than (but just as understandable as) a def statement?
_______________________________________________
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/5OT2TMDLJKNHKFM7MHUY7OURVWZSCZQI/
Code of Conduct: http://python.org/psf/codeofconduct/
