On Wed, Jul 05, 2017 at 03:29:35PM +0200, Matthias Bussonnier wrote: > Hi all, > > I want to point out that if it's not common to dispatch on values of > exceptions it might be **because** it is hard to do or to know wether > an exception will be structured or not.
It "might be" for a lot of reasons. The argument that "if Python did X, we might find a use for X" could be used to justify any idea at all, regardless of its usefulness. I found your post ironic -- after spending many paragraphs complaining that exceptions aren't structured enough, that people won't write structured exception classes or make use of structured exceptions "if it's not encouraged by the core" (your words), you then run a grep over your code and find (by my rough count) nearly 100 examples of structured exceptions. So it seems to me that third party libraries are already doing what you say they won't do unless the core exceptions lead the way: providing structured exceptions. Just a handful of examples from your grep: > gh-activity/ghactivity.py: e.repo > pypi/store.py: e.code > cpython/Lib/nntplib.py: e.response > cpython/Lib/runpy.py: e.name > jupyter_client/jupyter_client/manager.py: e.winerror > jupyterhub/jupyterhub/utils.py: e.code > qtconsole/qtconsole/console_widget.py: e.mimeData > xonsh/xonsh/execer.py: e.loc > django/django/forms/fields.py: e.error_list > django/django/http/multipartparser.py: e.connection_reset > cpython/Lib/asyncio/streams.py: e.consumed > ipyparallel/ipyparallel/client/client.py: e.engine_info > jedi/jedi/api/completion.py: e.error_leaf and more. Third parties *are* providing rich exception APIs where it makes sense to do so, using the interface encouraged by PEP 352 (named attributes), without needing a default "StructuredException" in the core language. > If Exceptions were by default > more structured, if CPython would provide a default > "StructuredException", As I said earlier, perhaps I'm just not sufficiently imaginative, but I don't think you can solve the problem of providing better structure to exceptions with a simple hack on BaseException. (And a complicated hack would have costs of its own.) I've come to the conclusion that there's no substitute for tackling each individual exception class individually, deciding whether or not it makes sense for it to be structured, and give it the structure needed for that exception. > or were the norm because CPython would use > more of them – then you might see more use case, and new code > patterns. And you might not. You might spend hours or days or weeks adding bloat to exceptions for no purpose. That's why we typically insist on good use-cases for new features before accepting them. If we accepted even 10% of the ideas proposed, Python would be a bloated, inconsistent, hard to use mess. (Actually I plucked that number out of thin air. It would be an interesting project to look at what proportion of ideas end up being accepted.) -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
