[ty] Make dataclass instances adhere to DataclassInstance#18115
Conversation
|
| They can be passed into `fields` as well, because it also accepts `type[DataclassInstance]` | ||
| arguments: |
There was a problem hiding this comment.
This just passes "by accident" at the moment (because we still think that class objects themselves are also instances of the DataclassInstance protocol, and fields accepts DataclassInstance | type[DataclassInstance]), but I formulated it in such a way that it will be correct eventually.
| )) | ||
| .with_qualifiers(TypeQualifiers::CLASS_VAR); | ||
| } | ||
|
|
There was a problem hiding this comment.
After moving this here, the test static_assert(is_subtype_of(Foo, DataclassInstance)) will (incorrectly) start passing, right?
Should that be added as a TODO, along with the asdict TODO in the tests?
There was a problem hiding this comment.
After moving this here, the test
static_assert(is_subtype_of(Foo, DataclassInstance))will (incorrectly) start passing, right?
Yes, I think so. I did not add this test, but a similar one (passing Foo to asdict). Feel free to suggest this as a follow-up (with a TODO), if you think it makes sense to add.
There was a problem hiding this comment.
Maybe I'm missing something here, but I think static_assert(is_subtype_of(Foo, DataclassInstance)) is correct and should pass. is_subtype_of takes type expressions, and the type expression Foo does not describe a class literal type, it describes the type of all instances of Foo. That type is a subtype of DataclassInstance.
(In the previous PR on this topic I made a comment about a wrong test, but that comment was wrong :) I thought the test fields(Foo) should fail because the class object Foo does not inhabit DataclassInstance. The latter is right, but fields(Foo) should still succeed because fields also accepts type[DataclassInstance].)
The test which should eventually not pass would be is_subtype_of(type[Foo], DataclassInstance) or is_subtype_of(ty_extensions.TypeOf[Foo], DataclassInstance). (The former tests what we call a SubclassOf type, the latter a ClassLiteral type.)
| # TODO: this should be a invalid-argument-type error, but we don't properly check the | ||
| # types (and more importantly, the `ClassVar` type qualifier) of protocol members yet. | ||
| asdict(Foo) | ||
| ``` |
There was a problem hiding this comment.
There's also astuple with a similar signature. Should that also be included in the tests?
There was a problem hiding this comment.
Sure, that would make sense.
…18115) ## Summary Make dataclass instances adhere to the `DataclassInstance` protocol. fixes astral-sh/ty#400 ## Test Plan New Markdown tests
Summary
Make dataclass instances adhere to the
DataclassInstanceprotocol.fixes astral-sh/ty#400
Test Plan
New Markdown tests