in basedpyright/pycharm the explicit usage of ABCMeta/ABC causes the class to be treated as abstract and report an error

Hmm, isn't that a bug in those tools? These classes don't have any abstract methods on them. Having ABCMeta as the metaclass isn't sufficient to make a class abstract. Lots of classes have that metaclass but can still be soundly instantiated at runtime

Hmm, isn't that a bug in those tools? These classes don't have any abstract methods on them. Having ABCMeta as the metaclass isn't sufficient to make a class abstract. Lots of classes have that metaclass but can still be soundly instantiated at runtime

no, it's intended behaviour, most languages with abstract classes work like that: https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMi4zLjEwIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiYWJzdHJhY3QgY2xhc3MgQVxuXG5mdW4gbWFpbigpIHtcbiAgICBBKClcbn0ifQ==

so the author of the class can indicate: "you shouldn't instantiate this class directly, it's abstract. you should subtype it"

no, it's intended behaviour, most languages with abstract classes work like that

that's certainly interesting, but it's not how Python works at runtime and I think type checkers should follow the runtime here. No other type checker has this behaviour -- here's a gist you can load into multiplay: 4abd6426cf1b97d8453e1822236246f9.

but it's not how Python works at runtime and I think type checkers should follow the runtime here.

at runtime python doesn't care about type annotations, so to say that we should always be as relaxed as the runtime permits isn't valid to me. i think this is a matter of opinion, i think it is a very valuable addition to the type checker that i have taken advantage of in my work, and the need for it was what motivated me and others to implement it to begin with

of course i wouldn't want to corrupt typeshed to appease some bizarre non-standard feature, but for this specific case, it is a simple fix that removes some false positives from these tools

I think it's fair to assume that if the user explicitly specifies metaclass=ABCMeta on a class, that they've done this with the intention of marking the class as abstract, regardless of whether there are @abstractmethods present.
That's why these tools consider instantiating such classes to be a likely source of issues, or at least a code smell.
And yes, it's possible to do at runtime. But that doesn't mean that it's good idea to rely on it. Ruff, for example, reports errors in cases like this all the time.

This change avoids triggering false positives in tools that assume this with minimal downsides. So I don't see why this shouldn't be put in. Besides, this wouldn't be the first tool-specific code in typeshed (or any other stub packages for that matter).

Whether or not this behavior should be changed in the typing spec is a different story, but I don't see why that should be required here.

I don't see why we can't just inherit from AbstractContextManager[Any]

in this case the Any wins over the Self in the subtype, making it really untyped. the only viable solution i can think of is to add a parameter to ExitStack:

_TExitStack_co = TypeVar("_TExitStack_co", default=ExitStack)

class ExitStack(_BaseExitStack[_ExitT_co], AbstractContextManager[_TExitStack_co]):

class Thing(ExitStack[bool | None, "Thing"]): ...

but this seems really clunky

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉