Closed mikeshardmind closed 4 months ago
I approve.
I'm good with this change too.
Looks good to me.
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?)
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.
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.
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
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.