[ty] treat properties as full structural types#23925
Merged
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 85.29%. The percentage of expected errors that received a diagnostic held steady at 78.13%. The number of fully passing files held steady at 64/132. |
charliermarsh
approved these changes
Mar 13, 2026
Member
charliermarsh
left a comment
There was a problem hiding this comment.
Nice summary, this makes sense to me.
Memory usage reportSummary
Significant changesClick to expand detailed breakdownsphinx
|
|
f267eee to
9f27d7c
Compare
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
unresolved-attribute |
0 | 0 | 1 |
| Total | 0 | 0 | 1 |
Contributor
Author
|
Hmm, ecosystem report shows that since we always display properties as just EDIT: It kinda seems like we should always show more information, since we are certainly (in various ways) treating it as a more specific type than the general EDIT 2: This is showing up rarely enough (exactly once in the ecosystem) that I'm inclined to leave it to a separate lower-priority follow-up, if or when someone complains about it. |
carljm
added a commit
that referenced
this pull request
Mar 13, 2026
* main: (94 commits) Fix shell injection via `shell=True` in subprocess calls (#23894) [ty] Refactor `relation.rs` to store state on a struct rather than passing around 7 arguments every time we recurse (#23837) Don't return code actions for non-Python documents (#23905) [ty] Make the default database truly statically infallible (#23929) [ty] Add `Download` button to ty playground which creates a zip export (#23478) [ty] Respect `kw_only` overwrites in dataclasses (#23930) [ty] Clarify in diagnostics that `from __future__ import annotations` only stringifies type annotations (#23928) [ty] Add a `Copy Markdown` button to playground (#23002) [ty] Fix folding range classification of lines starting with `#` (#23831) [ty] Fix folding ranges for notebooks (#23830) [ty] fix too-many-cycle panics when inferring literal type loop variables (#23875) Add `RegularCallableTypeOf` and `into_regular_callable` in `ty_extensions` (#23909) [ty] treat properties as full structural types (#23925) [ty] Avoid duplicated work during multi-inference (#23923) [ty]: make `possibly-missing-attribute` ignored by default [ty]: split out `possibly-missing-submodule` from `possibly-missing-attribute` Update astral-sh/setup-uv action to v7.5.0 (#23922) [ty] Show truthiness in ConstraintSet display and simplify falsy error message (#23913) Bump 0.15.6 (#23919) [ty] Narrow type context during collection literal inference (#23844) ...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes astral-sh/ty#3032
The bug there was that type relation judgements between two
PropertyInstanceended up falling back on both sides to usingKnownClass::Property, meaning that we would always consider any twoPropertyInstance(even with entirely different getters/setters) as equivalent.Fixing this bug required more clearly deciding on the semantics of a
PropertyInstancetype. Either it is a singleton type representing exactly one property object, or else it is a structural type with getter and setter members and full structural subtype relations accordingly.The existing code sort of leaned towards the singleton understanding, but that interpretation isn't sustainable consistently with the current Salsa-interned implementation of
PropertyInstanceType. If we create two different properties in our Python code, but with the same getter and setter type, those will become the same Salsa-internedPropertyInstanceType, and thus necessarily treated as equivalent. In other words, we can't truly treat a type as a singleton type unless it is either known to be interned at runtime (e.g.None), or its Salsa-interned attributes include aDefinitionor similar differentiator (e.g. class and function literals).So I instead chose to go the other direction, and implement full structural type relations for
PropertyInstanceType, which isn't that complex since they only have two possible attributes.Test Plan
Added an mdtest which fails on main representing the user-observable behavior where a union of property instances collapsed.
Added comprehensive mdtests for type relations between property instances.