-
Notifications
You must be signed in to change notification settings - Fork 21
Updated type annotations to match those in typeshed #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
995b91b
to
5d0e783
Compare
Pull Request Test Coverage Report for Build 3456826194
💛 - Coveralls |
@Zac-HD do you have interest in reviewing this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to review, looks good though two questions below:
) -> tuple[BaseExceptionGroup[_BaseExceptionT] | None, Self | None] | tuple[ | ||
Self | None, Self | None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not seeing how we get a non-Self
case from this, since we're using .derive()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure; maybe my implementation misses a case? This is how it was annotated in the typeshed though, so 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, might be a typeshed bug then? I'd be fine with merging it as-is though; it doesn't seem particularly important to investigate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, got it: the correct return-type annotation is tuple[BaseExceptionGroup[_BaseExceptionT] | None, BaseExceptionGroup[_BaseExceptionT] | None]
, no use of Self
or overrides. That's because the more precise annotation is only true for subclasses which implement .derive()
, in which case they should also ship more precise (but still not Self
) annotations for .subgroup()
and .split()
.
I'll open an upstream issue against typeshed shortly.
def __new__(cls, __message: str, __exceptions: Sequence[_ExceptionT_co]) -> Self: | ||
instance: ExceptionGroup[_ExceptionT_co] = super().__new__( | ||
cls, __message, __exceptions | ||
) | ||
if cls is ExceptionGroup: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be if issubclass(cls, Exception)
(or ExceptionGroup
)? As-is I could subclass ExceptionGroup
and then store a BaseException
in that just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is how the upstream implementation works too. Try running this on Python 3.11:
class CustomExcGroup(ExceptionGroup):
pass
exc = CustomExcGroup("message", [SystemExit(), ValueError()])
Works fine. This is somewhat covered in PEP 654: https://peps.python.org/pep-0654/#subclassing-exception-groups
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I should probably go complain ask about this upstream 😅
Thanks for the quick response! This was actually blocking an important upcoming AnyIO changeset from passing mypy checks. |
Glad I could help! |
No description provided.