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 MyExceptio
n'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 wrote:
>
>> Exception definitions in Python are not great. There are two
d to continue this discussion.
On Thu, Aug 8, 2019 at 4:12 PM Andrew Barnert wrote:
> On Aug 8, 2019, at 08:52, Ryan Fox wrote:
> >
> > >>> class MyException(Exception):
> > ... def __init__(self, action, context):
> > ... super().__init__(f&#x
t;
>>
>>
>> On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft wrote:
>>
>>>
>>>
>>> On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
>>> [email protected]> wrote:
>>>
>>>> On Aug 8, 2019, at
f) else
obj.field.of.interest
obj.get('field', {}).get('of', {}).get('interest')
(The first example shows how it would be handled with the PEP in its
current state.)
Maybe these are too far out of scope, I'm not sure. They feel very similar
to me though.
>
> No, the conditional branching would be based on exists.__bool__ (or,
> in the current working draft, is_not_none.__bool__), and that would be
> "0 is not None", which would be True and hence short-circuit.
>
>
> `__then__` is responsible for *unwrapping* the original value from the
> circuit b
