If the __exit__ is marked as returning bool, recent versions of mypy will assume it can swallow exceptions and will complain that code like
def fn() -> int:
with context():
if something:
raise ValueError
return 42
has a missing return statement after the with.
CancelScope can swallow exceptions, and in most cases where you'd use a cancel scope you care about the control flow when cancelled, so it keeps a bool return type from __exit__.
open_nursery() is declared to return an aribtrary AsyncContextManager[None] and mypy empirically does not seem to assume that those might swallow exceptions for control flow purposes. Nurseries contain a cancel scope, so if anyone says nursery.cancel_scope.cancel() then the "jump to right after the nursery" control flow path will exist. Not all uses of a nursery will directly access its cancel scope, though, so it seems better to me to avoid the false positive in this case.
If the
__exit__
is marked as returningbool
, recent versions of mypy will assume it can swallow exceptions and will complain that code likehas a missing return statement after the
with
.CancelScope can swallow exceptions, and in most cases where you'd use a cancel scope you care about the control flow when cancelled, so it keeps a
bool
return type from__exit__
.open_nursery()
is declared to return an aribtraryAsyncContextManager[None]
and mypy empirically does not seem to assume that those might swallow exceptions for control flow purposes. Nurseries contain a cancel scope, so if anyone saysnursery.cancel_scope.cancel()
then the "jump to right after the nursery" control flow path will exist. Not all uses of a nursery will directly access its cancel scope, though, so it seems better to me to avoid the false positive in this case.