[dataclass_transform] detect transform spec changes in incremental mode#14695
Conversation
| tuple(snapshot_type(tdef) for tdef in node.defn.type_vars), | ||
| [snapshot_type(base) for base in node.bases], | ||
| [snapshot_type(p) for p in node._promote], | ||
| node.dataclass_transform_spec or find_dataclass_transform_spec(node), |
There was a problem hiding this comment.
this may be somewhat expensive; an alternative may be to attach the relevant spec to each class in the hierarchy during semantic analysis rather than only attaching the spec to the transformer class
There was a problem hiding this comment.
Class hierarchies are almost always quite shallow, so this shouldn't be expensive. Similar to above, the snapshots must support equality. Using the serialized form should do the trick.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
JukkaL
left a comment
JukkaL
left a comment
There was a problem hiding this comment.
The main thing here that doesn't seem right is that snapshots should only contain objects that support value-based equality. You can also add some test cases to test-data/unit/diff.test which tests the astdiff module.
| node.is_static, | ||
| signature, | ||
| is_trivial_body, | ||
| dataclass_transform_spec, |
There was a problem hiding this comment.
This doesn't support equality and can't be used in snapshots. You can probably use the serialized form instead.
| tuple(snapshot_type(tdef) for tdef in node.defn.type_vars), | ||
| [snapshot_type(base) for base in node.bases], | ||
| [snapshot_type(p) for p in node._promote], | ||
| node.dataclass_transform_spec or find_dataclass_transform_spec(node), |
There was a problem hiding this comment.
Class hierarchies are almost always quite shallow, so this shouldn't be expensive. Similar to above, the snapshots must support equality. Using the serialized form should do the trick.
| @dataclass_transform() | ||
| class Dataclass: ... | ||
|
|
||
| class A(Dataclass): |
There was a problem hiding this comment.
Here the change in MRO will trigger dependencies, so this doesn't perfectly test how applying dataclass transform behaves. You can work around this by having a Dataclass base class in the original version, but omit the dataclass_transform decorator.
wesleywright
changed the title
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
… incremental mode (python#14695) Adds support for triggering rechecking of downstream classes when `@dataclass_transform` is added or removed from a function/class, as well as when parameters to `dataclass_transform` are updated. These changes aren't propagated normally since they don't change the type signature of the `dataclass_transform` decorator. Also adds new a new `find-grained-dataclass-transform.test` file to test the new logic. (cherry picked from commit 29bcc7f)
… incremental mode (#14695) (#14768) Adds support for triggering rechecking of downstream classes when `@dataclass_transform` is added or removed from a function/class, as well as when parameters to `dataclass_transform` are updated. These changes aren't propagated normally since they don't change the type signature of the `dataclass_transform` decorator. Also adds new a new `find-grained-dataclass-transform.test` file to test the new logic. (cherry picked from commit 29bcc7f) Co-authored-by: Wesley Collin Wright <wesleyw@dropbox.com>
2 participants
Adds support for triggering rechecking of downstream classes when
@dataclass_transformis added or removed from a function/class, as well as when parameters todataclass_transformare updated. These changes aren't propagated normally since they don't change the type signature of thedataclass_transformdecorator.Also adds new a new
find-grained-dataclass-transform.testfile to test the new logic.