[Withdrawn] Typing spec update handling Any as a base type

[mikeshardmind]

I'd like to request codifying the existing behavior for how Any is handled as a base in the MRO of classes.

Links to PR & Discussion

PR: https://github.com/python/typing/pull/1672 Discussion: https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981

Current Type Checker Behaviors

The below has been edited after more testing surfaced that no type checker is completely consistent with this and that there is divergence between type checkers on behavior, see the tests added to the conformance suite in linked PR

• Currently, pyright and mypy and pytype support Any as a base class. None of the 3 are fully compliant with this wording, and each currently differ in behavior here.
• pyre does not yet support any as a base class.
• I'm unaware of other type checkers that have support for this at this time.
• This is also consistent with the behavior of type[Any]

Controversial Issues

There are multiple reasonable interpretations of type theory leading to the current behavior, as well as alternative behavior, and it may or may not be beneficial to codify one of them at this time. The current changeset does not commit to a specific rationale for this.

The potential alternative behavior is more theory-pure and not something that had support within the discussion, being seen as too disruptive to users.

[JelleZijlstra]

I approve.

[erictraut]

I'm good with this change too.

[rchen152]

Looks good to me.

[gvanrossum]

I'm good with the addition to the spec. I have no opinion on the test changes. (But Eric seems to have an unresolved comment?)

[erictraut]

I just ran into a problem when attempting to implement this proposed change in pyright. See this post. I think we need to bottom out on this issue before we can accept the change.

[mikeshardmind]

Thank you for your time in considering this. Unfortunately, it appears to require a significantly larger change with a larger scope once the interactions with the special casing of constructors and __getattr__ were examined in more detail, at least concerning my motivations for improving this.

I don't think a change of that scope is something I'm prepared to present at this point, it would significantly alter gradual typing in general for type checkers, asking them to keep track of a lower and upper bound for gradual types, the lower representing what was known for certain about the type of a value with compatibility being assumed, and the upper representing the upper limit of what was allowed within the framework of gradual typing without being considered a type error.

Keeping track of both independently would enable better inference around hasattr, isinstance, and a few others, but probably most importantly, would retain capabilities for some of the use cases of typing like language servers using type information to only serve autocompletion for things that are known to exist, which was noted here in the discussion as being a reason that some of the theory-based approaches, could degrade the user experience of those who only use typing indirectly.

The problems this poses with simple subclassing will also arise with the current approach to intersections, so my next steps on wrapping this up will be to follow up with others involved in that discussion with a summary of my findings so that anyone continuing to work on it is on the same page on the obstacles.

I don't think this is a compelling enough reason to rush through such a large change to how gradual types are handled or likely to be a good use of the typing community's time given other inconsistencies that are likely to be more impactful for less effort expended at the current moment. I may continue to work through some of these ideas independently or with others at a later point in time.

Thank you again for the time spent considering this.