Yep, I think calling get_origin() on generics to 'unwrap' the bare type as part of this code would be a great fix. Would you be interested in opening a PR?

I'll take a shot at it.

The only hesitation is that it may look somewhat misleading in that we would still actually catch all ExceptionGroups and don't validate that only the given exception class is actually contained.

i.e. the following satisfying the logic of raises without a single ValueError being thrown.

with pytest.raises(ExceptionGroup[ValueError]) as exc_info:
    raise ExceptionGroup("Some errors occurred", [RuntimeException("Normal error occurred")])

# Of course if you add an assert group_contains which is how I would use it
assert exc_info.group_contains(ValueError)

There are some similarities to the standard isinstance(list_of_ints, list[str]) where the choice was to not support it.

I personally still think practicality beats purity here and that the narrower focus and implied experience-level of pytest users (especially users of pytest.raises with ExceptionGroup and strong typing) but wanted to check.

Of course you can dig deeper and recognize a parametrized ExceptionGroup, extract the parametrized type and if it's an exception do some further magic with ExceptionGroup split but that feels a bit too far with an endless can of worms waiting.

The only hesitation is that it may look somewhat misleading in that we would still actually catch all ExceptionGroups and don't validate that only the given exception class is actually contained.

Hmm, that's a good point, and actually does make me more nervous about just unwrapping the generic - "tests check less than the developer expected" is a classic way for bugs to sneak through to production.

We've actually been working on #12504 via trio.testing.RaisesGroup() (eg in python-trio/trio#3145), with the goal of merging it into Pytest once the API has been shaken out a bit. Maybe we could push people towards RaisesGroup if their annotation is more precise than (Base)ExceptionGroup[Any / (Base)Exception], so there's a clean syntax that strict type-checkers allow but without leaving the implication that we're checking anything more precise than we actually are? (which would imply waiting, ugh)

For all my uses just always using the full ExceptionGroup[Exception] or similar even with ExceptionGroup[Any] would be fine but all of those still results in a GenericAlias which fails at runtime.

The real annoyance and problem for me/us here is really only that ExceptionGroup is generic but without a default type-argument which causes pyright/pylance to complain about the resulting type of the return value being incomplete/unspecified on the stricter setting and there being no really good place to add it as you can't simply type-annotate the result of a context-manager.

I do realize that is a quite narrow and specific concern though with annoying/ugly but fully functional workarounds so this is not really something pressing.

Loose thought without thinking too deep would be if it would be worth it if runtime could accept just the explicit common types ExceptionGroup[Exception], BaseExceptionGroup[BaseException] and maybe Any as well for argument and raise for anything else.

Yep, I'd be happy to accept a PR for that minimal version anytime.

I added a PR with discussed fixes (Only accepts specifically ExceptionGroup[Exception] and BaseExceptionGroup[Exception]. with a hopefully meaningful error message for others).

A bit larger patch than I would've liked due to the need to handle them in tuples as well but seems to work well both on versions with native support and without. Was a bit unsure about where to add the tests so some feedback on the PR would be welcome.