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/