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
boolreturn 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.