Visitar URL original
Subclasses of `ExceptionGroup` can wrap `BaseException`s · Issue #99553 · python/cpython · GitHub
Skip to content

Subclasses of ExceptionGroup can wrap BaseExceptions #99553

Description

@Zac-HD
class MyEG(ExceptionGroup):
    """Holds BaseExceptions without itself being a BaseException."""

oops = MyEG("oops", [KeyboardInterrupt()])
assert isinstance(oops, Exception)
assert not isinstance(oops.exceptions[0], Exception)

I believe that this is a bug tracing to the period when PEP-654 did not intend (Base)ExceptionGroup to be usable as a parent class; and I think a sufficient fix would be to replace the type-equality check with an isinstance check in:

if (cls == PyExc_ExceptionGroup) {
if (nested_base_exceptions) {
PyErr_SetString(PyExc_TypeError,
"Cannot nest BaseExceptions in an ExceptionGroup");
goto error;

cc @iritkatriel; raised via agronholm/exceptiongroup#40 (comment)

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Nov 17, 2022
  2. iritkatriel commented on Nov 17, 2022

    @iritkatriel
    Member

    I believe we discussed this and decided that we leave it to the subclass author to deal with it. Maybe it needs to be documented (or reconsidered)?

    CC @gvanrossum @1st1

  3. Zac-HD commented on Nov 17, 2022

    @Zac-HD
    ContributorAuthor

    I think at least documented, though I'd prefer it was changed.

    If people intend MyEG to contain BaseExceptions then the obvious way is to inherit from BaseExceptionGroup (and likely have a BaseMyEg; Trio has already shipped this pattern), so any cases where MyEG ends up containing e.g. a KeyboardInterrupt and then discarding that to an except Exception: would be unfortunate! I think the PEP argues against this well 🙂

    The == comparison also makes static typing very confusing: if we have BaseExceptionGroup -> ExceptionGroup -> MyEG and the last can also contain BaseExceptions, then either ExceptionGroup.exceptions must be annotated as able to contain BaseExceptions when it cannot, the annotations for MyEG must say it cannot when in fact it can, or we violate the substitution principle. This last is currently the case at runtime, but typecheckers are not keen on such things.

  4. Zac-HD commented on Nov 17, 2022

    @Zac-HD
    ContributorAuthor

    Hah! It looks like I just find this persistently startling: #28569 (comment) (but I promise, no PEP this time 😉)

  5. gvanrossum commented on Nov 17, 2022

    @gvanrossum
    Member

    Yeah, I definitely recall that we discussed this before. But looking at the code it's possible that we were too conservative. In particular in the fallback clause we could have chosen to check if cls is a subclass of PyExc_ExceptionGroup if nested_base_exceptions is set and raise the same error as on line 742.

    The thing we definitely can't do is adjusting the class if it is exactly PyExc_BaseExceptionGroup and nested_base_exceptions is false.

    The question is, can we treat this as a bug and fix it (in 3.11.1 if it isn't out yet) or would such a fix be considered backwards compatible?

  6. iritkatriel commented on Nov 17, 2022

    @iritkatriel
    Member

    I think we can call it a bug. It’s better to change it in 3.11.1 than in 3.12.

  7. gvanrossum commented on Nov 17, 2022

    @gvanrossum
    Member

    Sounds good.

  8. added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    3.11only security fixes
    3.12only security fixes
    on Nov 18, 2022
  9. added a commit that references this issue on Nov 18, 2022
  10. added a commit that references this issue on Nov 18, 2022
  11. added 2 commits that reference this issue on Nov 18, 2022
  12. added a commit that references this issue on Nov 20, 2022
  13. added a commit that references this issue on Apr 11, 2023
  14. added 2 commits that reference this issue on Apr 11, 2023
  15. added a commit that references this issue on Apr 11, 2023
  16. added a commit that references this issue on Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.11only security fixes3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions