On 2020-04-11 8:39 p.m., Dominik Vilsmeier wrote:
If I understand correctly, you want a way for distinguishing between
exceptions that were explicitly and intentionally `raise`'ed as part
of an API and exceptions that were unintentionally raised due to bugs.
So for example:
raise ValueError(f'Illegal value for xyz: {xyz}') # part of the API
foo['bug'] # this should have been 'bag' so it's a bug
In addition to that, the user of the API should be able to decide
whether they let the API raise in their *exception space* or not.
I think you could realize this in today's Python by using `raise ...
from espace` where espace is an instance of a custom exception and
then check the resulting exception's `__cause__`. So for example:
class ESpace(Exception):
pass
# I'm the user of an API and I want to distinguish their API
errors from bugs.
espace = ESpace()
try:
api_func(espace=espace)
except KeyError as err:
if err.__cause__ is espace: # it's part of the API
pass
else: # it's a bug
pass
And the API functions would have to raise their exceptions explicitly
from the provided `espace`:
def api_func(espace=None):
raise KeyError() from espace # part of the API; sets the
exception's __cause__ to `espace`
foo['bug'] # here __cause__ will be None, just like if no
`espace` had been provided
It's probably an abuse of the exception mechanism and also relies on a
dunder, but for your own projects it could serve the purpose.
I figured something better instead. you can have a class ESpace, but you
use it like so:
espace = ESpace()
try:
foo(espace=espace)
except espace.module.submodule.Exception:
...
e.g. for builtins:
espace = ESpace()
try:
raise espace.ValueError
except espace.ValueError:
...
and it dynamically creates subclasses of whatever you give it. I'm not
sure how doable this is in current python, but it's super close to what
I want. so hey if it works well, we can promote it to the stdlib? just
need to encourage ppl not to check the type of their espace argument so
you can silently swap the external one for the stdlib one and nothing
breaks.
(still need a better way to pass it into operators but eh)
On 11.04.20 18:07, Soni L. wrote:
the reason I'm proposing this is that I like standard exception types
having well-defined semantics. this "special, very fragile, syntax
for the same purpose" doesn't take away from that, and instead just
adds to it.
it's a way of having multiple, independent, "local" dynamic scopes.
instead of just one global dynamic scope. and enables you to freely
use standard exception types.
if anything it's closer to passing in a namespace with a bunch of
standard exception types every time you wanna do stuff. which... I
could also get behind tbh. an stdlib addition that dynamically
exposes subclasses of the standard exception types, unique to that
namespace instance. would still need some way of passing it in to
operators and stuff tho.
_______________________________________________
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/HAT3Y77ONNJ5VKOFH6ZPFQ3LZXEQB2Q4/
Code of Conduct:http://python.org/psf/codeofconduct/
_______________________________________________
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/X7YXXEBILZNA52UUDN7PC4R6RHVAIXGO/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/44WBWPOA36S2H5ZLUEFIZXUHG2AZGYHS/
Code of Conduct: http://python.org/psf/codeofconduct/