-
Notifications
You must be signed in to change notification settings - Fork 163
InitVar Fields are not instance attributes in dataclasses #437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ation` to determine if a field is an InitVar. Updated `get_instance_attribute` to prevent access to InitVar fields as instance attributes. Added a test case to verify that InitVar fields are not accessible as instance attributes.
@srchilukoori has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@Adist319 Internal test failed due to conformance output is out of date, could you run the |
Hmm, based on the docs I think we shouldn't be counting it as a field at all - blocking it only when accessing it as an instance attr can cause it to leak in other places. For example, accessing it as a class var:
Would it be possible to make it not create a ClassField at all? Or have it be omitted from I would also expect this to generate a conformance test change - does |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! back to you w/ some comments on the overall approach
Thanks for the comments @yangdanny97 will look into this. |
InitVar Filtering RegressionsI currently have changes where I refactored the attribute access methods ( What's happeningThe dataclass tests are failing with errors like "Expected 0 positional arguments, got 1 in function
It looks like the type checker is falling back to The problem (from my understanding, correct me if I'm wrong)
When I filter InitVar fields, the dataclass generation can't access the field info it needs anymore. QuestionWhat's the cleanest way to handle this? Should I create separate methods for these two use cases, or is there a better approach I'm missing? |
I see what you mean. Maybe blocking it from get_instance_attribute/get_class_attribute is enough. We could add a special case pyrefly/pyrefly/lib/alt/class/class_field.rs Line 863 in abba427
|
@yangdanny97 I think this could work, let me try it out. Thanks for the feedback. |
I've implemented your suggestions, @yangdanny97, but I keep hitting the same regressions, which makes me think there’s a deeper architectural issue I’m not seeing. Core problemHere's my current understanding and what I tried doing in addition: It looks like the dataclass That creates a Catch-22:
I tried restoring What I’m trying to figure outIs there a clean way to pass context down through the solver so the attribute resolver knows whether it's being called during Feels like I need a scoped flag or mode that tells Would appreciate any guidance on how this is supposed to be handled in the current architecture. |
Hmm, that's unexpected. I thought it only uses |
@yangdanny97 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Ok, I think I got something working with this. The tricky part was getting The diff is as follows:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review automatically exported from Phabricator review in Meta.
@yangdanny97 merged this pull request in f32c44e. |
Summary
This PR addresses Issue #409 by ensuring that
InitVar
fields are not treated as instance attributes in dataclasses.fixes #409
Changes
is_init_var
in bothClassField
andAnnotation
to determine whether a field is anInitVar
.get_instance_attribute
to prevent access toInitVar
fields as instance attributes.InitVar
fields are correctly excluded from instance attribute access.