# Compatibility of protocol class object with \`type\[T\]\` and \`type\[Any\]\`

**URL:** <https://discuss.python.org/t/compatibility-of-protocol-class-object-with-type-t-and-type-any/48442>\
**Category:** Typing\
**Created:** [March 14, 2024, 1:56am UTC](https://discuss.python.org/t/compatibility-of-protocol-class-object-with-type-t-and-type-any/48442 "2024-03-14T01:56:22Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![mdrissi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mdrissi/32/5427_2.png) [@mdrissi](https://discuss.python.org/u/mdrissi)\
**Post date:** [March 14, 2024, 6:12am UTC](https://discuss.python.org/t/compatibility-of-protocol-class-object-with-type-t-and-type-any/48442/3 "2024-03-14T06:12:27Z")

</div>

My own experience is I have passed abstract classes to type[T] where function was able to handle that without an issue. Passing a type does not imply the use case is to instantiate it directly. I don’t think I have examples of passing protocol to a type[T], although that’s because I tend to see more libraries with abstract classes then protocols. There’s a lot of common abstract classses in standard library but few (not sure of any) protocols there. I do not see a strong argument for why protocols vs abstract classes should differ in rules here.

So my own preference would lean towards,

```python
variables and parameters annotated with type[Proto] accept only concrete (non-protocol) subtypes of Proto

```

removing this entirely.

If not then how should code that does runtime type manipulations (singledispatch/config systems) handle this? We could have type[T] and ConcreteType[T] (or AbstractType[T]), but unsure extra special form is worth distinguishing the two. If answer is no option, then it mostly becomes noisy type ignore.

edit: [context:global ": type[T… - Sourcegraph](https://sourcegraph.com/search?q=context:global+%22:+type%5BT%5D%22+lang:Python+&patternType=keyword&sm=0) we can review usage patterns of type[T]. Too many to review but spot checking 4,

[First one](https://sourcegraph.com/github.com/getsentry/sentry@a6467b0170e2758ba80528303acd170a39ce014e/-/blob/src/bitfield/models.py?L205) uses it for a cast and abstract/protocol would work fine. [Second one](https://sourcegraph.com/github.com/Textualize/rich@0d7e598fe7ead1cca6b590c1de7f54ba19255d11/-/blob/rich/repr.py) modifies class attributes for documentation. That would work fine too with protocol. [Third one](https://sourcegraph.com/github.com/localstack/localstack@a6d6a3c758afbbbcd7ce03ee0e14e451eae61925/-/blob/localstack/utils/collections.py) is interesting. It does not work with protocols, but it also does not work with most concrete types. It is only for TypedDict types so really it’s closer to type[T: TypedDict] even though that’s not well defined in type system either. [Fourth one](https://sourcegraph.com/github.com/pytorch/pytorch@b4c53aa0ec418f61a424b7d5a7603eb4b96d150b/-/blob/torch/storage.py) looks like Self maybe written before Self existed?

---

_[View the full topic](https://discuss.python.org/t/compatibility-of-protocol-class-object-with-type-t-and-type-any/48442)._