On Thu, Aug 8, 2019 at 11:38 AM Ryan Fox <[email protected]> wrote: > Thanks for the comments. > > I'm not really sure what you mean with regards to backwards compatibility. > Would it suffice to have ExceptionTemplate.__init__ accept *args and pass > that into super().__init__? I see that BaseException does something with > args in __new__ and __init__, but I'm not very familiar with the Python > internals. How does BaseException deal with kwargs? >
It doesn't deal with them because it won't accept them. :) > > str.format_map() would make the formatting simpler, but I also use > string.Formatter.parse() to in ExceptionTemplate._error_check() to find the > required arguments. I don't see an alternative for this on str. > You can also use str.format(**kwargs) if you want to be strict about what you accept in terms of keyword arguments while being generic in your implementation. I also just realized that your class won't have any helpful introspection on the call signature either, so all users of your class will have to document in the docstring very clearly what is expected in the constructor call as their code editors won't be able to tell them and help()/inspect won't be able to help either. > > You're right about the third thing. I hadn't even considered the books! I > have released on PyPI as 'exception-template' and we'll see what happens. > One person commented on Reddit that they liked the idea but would probably > copy the code directly into their project rather than require an additional > external dependency. > Yep, this is small enough to easily fit into a person's personal toolbox of handy code. > > I guess I was hoping to get a feel of whether this was something that > appealed to this audience and/or could ever be accepted, as well as to > refine the idea and implementation. > > On Thu, Aug 8, 2019 at 2:03 PM Brett Cannon <[email protected]> wrote: > >> Three things. One, this isn't backwards-compatible as you are not passing >> any details down into Exception.__init__() to make sure that >> BaseException.args gets populated. >> >> Two, you can simplify your code by using str.format_map() instead of the >> string module. >> >> Three, I don't see enough overhead from version 2 to your version 3 since >> you're only saving a line of code so say there's that much boilerplate. But >> the best way to prove me wrong is to release this on PyPI and see if people >> use it. But without community use proving people want this we won't be up >> for adding a new built-in exception as you're asking every book on Python >> to be rewritten to cover this which is no small thing. >> >> On Thu, Aug 8, 2019 at 8:56 AM Ryan Fox <[email protected]> wrote: >> >>> Exception definitions in Python are not great. There are two main ways >>> they're used in the code that I've read: >>> >>> 1) By far the most common: >>> >>> >>> class MyException(Exception): >>> ... pass >>> >>> raise MyException(f'Bad thing happened during {action} in {context}') >>> >>> 2) Much rarer: >>> >>> >>> 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 1 is quick and easy, but messages skew and become inconsistent >>> as they're copied from place to place. The Python standard library isn't >>> immune to this either. >>> >>> 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) >>> >>> I have a reference implementation, implemented in an almost trivial >>> amount of pure Python code: >>> https://github.com/rcfox/exception-template/blob/master/exception_template/exception_template.py >>> >>> So why am I bothering you with this? I would like to see this become the >>> preferred method of defining new exceptions as recommended by the Python >>> documentation. This would also require adding ExceptionTemplate as a >>> built-in exception type. >>> >>> I will grant that ExceptionTemplate seems a little bit magical, but all >>> of the required arguments are explicitly laid out to the user in the >>> 'message' field, and format strings should be a familiar concept to most >>> users. >>> >>> I've also included some tests that show that you can still treat these >>> exceptions as regular classes: >>> https://github.com/rcfox/exception-template/blob/master/tests/test.py#L53 >>> >>> _______________________________________________ >>> Python-ideas mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/[email protected]/message/GEO2WZQQJ6HMSXZIRFCKTRM7TYFQXNZ2/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5UH6DA5W2KPZRJJ2FJ45FARSQ6DPIG6V/ Code of Conduct: http://python.org/psf/codeofconduct/
