Skip to content

Conversation

sharkdp
Copy link
Contributor

@sharkdp sharkdp commented Sep 10, 2025

Summary

closes astral-sh/ty#1156

Test Plan

Added a regression test

@sharkdp sharkdp added bug Something isn't working ty Multi-file analysis & type inference labels Sep 10, 2025
Copy link
Contributor

github-actions bot commented Sep 10, 2025

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

Copy link
Contributor

github-actions bot commented Sep 10, 2025

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

Comment on lines -5711 to -5713
let instance = Type::ClassLiteral(class).to_instance(db).expect(
"nearest_enclosing_class must return type that can be instantiated",
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This would previously use the "default" specialization, and so we would end up with an upper bound of Container[bytes] for the example in the mdtest. With the change here, we instead use Container[Unknown] as the upper bound.

```toml
[environment]
python-version = "3.11"
python-version = "3.13"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Default values for type parameters have only been introduced recently (https://peps.python.org/pep-0696/)

@sharkdp sharkdp marked this pull request as ready for review September 10, 2025 09:18
let instance = Type::ClassLiteral(class).to_instance(db).expect(
"nearest_enclosing_class must return type that can be instantiated",
);
let instance = Type::instance(db, class.unknown_specialization(db));
Copy link
Member

Choose a reason for hiding this comment

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

I wondered if class.top_materialization() would work here, but it looks like under the hood that uses default_specialization(), so it suffers from the same issue as our current logic on main. (It probably shouldn't use default_specialization()?)

Copy link
Member

Choose a reason for hiding this comment

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

It probably shouldn't use default_specialization()

I think you're right — it should translate typevars into the bound/constraints in covariant position, and to Never (the implicit lower bound of every typevar) in contravariant position. (With the caveat that we can't really express the constraints of a constrained typevar as a single type — we'd need a "one-of" connective instead of union, and an "instance of this type but not any subtypes".)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

@dcreager dcreager 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 for tracking this down!

let instance = Type::ClassLiteral(class).to_instance(db).expect(
"nearest_enclosing_class must return type that can be instantiated",
);
let instance = Type::instance(db, class.unknown_specialization(db));
Copy link
Member

Choose a reason for hiding this comment

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

It probably shouldn't use default_specialization()

I think you're right — it should translate typevars into the bound/constraints in covariant position, and to Never (the implicit lower bound of every typevar) in contravariant position. (With the caveat that we can't really express the constraints of a constrained typevar as a single type — we'd need a "one-of" connective instead of union, and an "instance of this type but not any subtypes".)

@sharkdp sharkdp merged commit 65982a1 into main Sep 10, 2025
38 checks passed
@sharkdp sharkdp deleted the david/fix-1156 branch September 10, 2025 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Initialization of generic classes with type parameter default values is broken

3 participants