I don't think there's enough of a win here for this to be worth it. twisted is just an optional backend for pika; if somebody decides to use tornado as a backend instead, then the extra dependency is pointless. And even if they do use twisted, the twisted types still don't seem fundamental to the package, really.

Just because we can have non-types dependencies now doesn't mean we should add them everywhere. We should still strive for stubs packages to have minimal dependencies, and present minimal security risks, wherever possible.

So it's an optional dependency just like Qt is to Pillow.

I don't think there's enough of a win here for this to be worth it.
[…] the twisted types still don't seem fundamental to the package, really

So would Any subclassing be acceptable here?
Or if its not too complex, I can look into replicating the base class(es) is the stub.

So would Any subclassing be acceptable here?
Or if its not too complex, I can look into replicating the base class(es) is the stub.

Any subclassing is never good exactly, so if you'd like to try mimicking the shape using protocols or whatever, sure 😀

I appreciate the work here but I'm wary of adding so much code that we can't validate with stubtest or other automatic tools.

It might make sense to import the types from Twisted without declaring an explicit dependency on Twisted for the stubs package. Users who use the Twisted backend presumably will also have Twisted installed in their venv, so they will get precise types. If they don't, type checkers will just fall back to Any.

It might make sense to import the types from Twisted without declaring an explicit dependency on Twisted for the stubs package.

That's something I've suggested a few times for different stubs with similar issues. (the idea of "optional" or "test only" dependencies). The issue with the current setup is that we can do that for stubtest, but not for every other tests like mypy, pyright, pytype, flake8, ... Especially with Pyright you can end up with unknowns that bubble up and you have to # pyright: ignore a bunch of stuff.

I'll see what I can do for Twisted in Pika, it's been a while I haven't touched this PR.

Alright, this is what it looks like in pika. Not too bad given that usage of twisted is restricted to the twisted_connection module.
I guess it technically solves subclassing Any? Even though mypy will still report it because the package is missing in test.
The same could be done for tornado_connection and gevent_connection.

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