On 8 Nov 2013 04:44, "Brett Cannon" <br...@python.org> wrote: > On Thu, Nov 7, 2013 at 7:41 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> The bigger problem is you can't change the constructor signature in a backwards incompatible way. You would need a new class method as an alternative constructor instead, or else use optional parameters. > > > The optional parameter approach is the one ImportError took for introducing its `name` and `path` attributes, so there is precedent. Currently it doesn't use a default exception message for backwards-compatibility, but adding one wouldn't be difficult technically. > > In the case of AttributeError, what you could do is follow the suggestion I made in http://bugs.python.org/issue18156 and add an `attr` keyword-only argument and correpsonding attribute to AttributeError. If you then add whatever other keyword arguments are needed to generate a good error message (`object` so you have the target, or at least get the string name to prevent gc issues for large objects?) you could construct the message lazily in the __str__ method very easily while also doing away with inconsistencies in the message which should make doctest users happy. Lazy message creation through __str__ does leave the message out of `args`, though. > > In a perfect world (Python 4 maybe?) BaseException would take a single argument which would be an optional message, `args` wouldn't exist, and people called `str(exc)` to get the message for the exception. That would allow subclasses to expand the API with keyword-only arguments to carry extra info and have reasonable default messages that were built on-demand when __str__ was called. It would also keep `args` from just being a dumping ground of stuff that has no structure except by calling convention (which is not how to do an API; explicit > implicit and all). IOW the original dream of PEP 352 ( http://python.org/dev/peps/pep-0352/#retracted-ideas).
A related problem (that rich exceptions cause, rather than solve) is one I encountered recently in trying to improve the error messages thrown by the codec machinery to ensure they mention the specific codec operation that failed: you can't easily create a copy of a rich exception with all the same attributes, but a different error message (at least through the C API - copy.copy may work at the Python level, but I don't want to make the codec infrastructure depend on the copy module). Rich exception types that require more than one parameter are also incompatible with PyErr_Format in general. For the current patch [1], I've "solved" the problem by whitelisting a common set of types that the chaining code knows how to handle, but it would be good to have some kind of BaseException.replace() API that did the heavy lifting and returned None rather than throwing an exception if replacement wasn't supported (since blindly bitwise copying instance objects isn't safe for subclasses that add extra C level pointers and throwing an exception would be really annoying for exception chaining code that wants to reraise the original exception if replacement isn't possible). Cheers, Nick. [1] http://bugs.python.org/issue17828
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
