On Tue, Feb 15, 2022 at 01:53:52AM -0800, Shantanu Jain wrote:
> As far as I'm aware, type checkers already support this. We inherit from
> Any in typeshed in a couple places. The need to support Any inheritance
> also arises naturally as a result of gradual typing, e.g. if your base
> class comes from an untyped library or the import cannot be resolved.
>
> I've used this trick myself a couple times and have seen use cases for this
> a couple times on gitter.im. It's a neat way to silence many errors from
> classes that do super dynamic things or to allow for classes that can duck
> type anywhere (e.g. mocks).
I don't understand why you need to subclass Any, instead of just using
Any. What's the subclass do that Any doesn't?
The canonical example is mock objects. In typeshed, unittest.mock.NonCallableMock is defined as (greatly simplified):
class NonCallableMock(Any):
def assert_any_call(self, *args: Any, **kwargs: Any) -> None: ...
def assert_has_calls(self, calls: Sequence[_Call], any_order: bool = ...) -> None: ...
def mock_add_spec(self, spec: Any, spec_set: bool = ...) -> None: ...
# ... many other methods
This makes it so you can pass a mock object to any function, regardless of its annotation, which is good because that's usually how you use mock objects. But it also means that the type checker knows what the signature of the `assert_has_calls` method is, and can tell you if you get it wrong.
Since this behavior is useful in stubs and we've been using it for a while, I think it makes sense to also allow it at runtime. This is a new feature, so it should go only into Python 3.11. We can then also provide a `typing_extensions.Any` that allows subclassing.
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: jelle.zijlstra@gmail.com