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/

Reply via email to