Skip to content

Conversation

@ericmarkmartin
Copy link
Contributor

Summary

What it says on the tin. See the typing spec for justification.

Test Plan

Add more tests to PEP 695 variance.md suite.

@github-actions
Copy link
Contributor

github-actions bot commented Sep 16, 2025

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

@github-actions
Copy link
Contributor

github-actions bot commented Sep 16, 2025

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

Comment on lines 755 to 783
## TypeIs

```toml
[environment]
python-version = "3.13"
```

`TypeIs[T]` is invariant in `T`. See the [typing spec][typeis-spec] for a justification.

```py
from typing import TypeIs
from ty_extensions import is_assignable_to, is_subtype_of, static_assert

class A:
pass

class B(A):
pass

assert not is_subtype_of(TypeIs[B], TypeIs[A])
assert not is_subtype_of(TypeIs[A], TypeIs[B])
assert not is_assignable_to(TypeIs[B], TypeIs[A])
assert not is_assignable_to(TypeIs[A], TypeIs[B])
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't TypeIs's variance already tested in is_subtype_of.md?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is interesting. The pre-existence of these tests implies the invariance was already being enforced? I'll have to look further

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the tests you added here fail before the code change in this PR?

It seems to me that what you are testing for here is assignability/subtyping of TypeIs types themselves (which I think was already correctly invariant), but the code change you made would not impact that, it would instead affect variance inference when you have e.g. TypeIs[T] as part of a method signature or as an attribute on a PEP695 generic class with typevar T. Which seems like a rare/unusual case, but still worth getting right.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I missed that there was existing logic for the in variance of TypeIs. Changed the tests, and also fixed assert -> static_assert 🙈

@AlexWaygood AlexWaygood added the ty Multi-file analysis & type inference label Sep 16, 2025
@AlexWaygood AlexWaygood changed the title Make TypeIs invariant in its type argument [ty] Make TypeIs invariant in its type argument Sep 16, 2025
@sharkdp sharkdp removed their request for review September 18, 2025 06:51
Copy link
Contributor

@carljm carljm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@carljm carljm merged commit 2502ff7 into astral-sh:main Sep 18, 2025
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants