# Take 2: Rules for subclassing Any

**URL:** <https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981>\
**Category:** Typing\
**Created:** [March 8, 2024, 3:09pm UTC](https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981 "2024-03-08T15:09:44Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [April 4, 2024, 2:14am UTC](https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981/23 "2024-04-04T02:14:39Z")

</div>

> [@Liz](#):
>
> how bad of a delay would it be on intersections to make reconciling the lower-bound problem part of that pep instead, and clarify the behavior of Any as part of that? It seems to me that intersections using ordering rather than the lower bound will have the same problems.

I don’t know that we can or should adopt that definition as part of intersections. That particular definition is much more closely related to ideas in set-theoretic typing than we currently have language for in Python’s typing specification, doing this would be a much larger set of changes to the specification and would more significantly codify the behavior of gradual types as a class (possibly a good thing, but a larger change).

One example of something _else_ that would be affected is `Callable[..., Any]`. In this `...` would be an expression of potential args and kwargs having bounds Lower: `()`, Upper: `(*args: Any, **kwargs: Any)`, and something that was glossed over before, but relevant here: being contravariant, the upper bound would be what was safe: (edit: safe _to assign with_, the lower bound _safe to call with_, sorry, expressing variance related stuff where we don’t have language for why it’s the case…), not the lower. (having worked this out, I need to go add detail to another current issue as well)

Adopting the definition has extremely predictable outcomes on intersections, but this might have surfaced as a large enough necessary change that might be worth an actual pep itself, and I think that those definitions also present a larger changeset for type checkers, but (as hinted at above) might solve multiple issues at once.

If the typing council would be comfortable with these changes being bundled initially, then split apart later if necessary, I could do it that way, but I don’t feel personally comfortable advocating for this being bundled with intersections rather than intersections relying on it.

Edit: I’m not going to pursue this approach right now, even if the typing council were comfortable with it, I’m not, to a degree that I wouldn’t do it.

---

_[View the full topic](https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981)._