Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork3.1k
Add support for converters with TypeVars on generic attrs classes#14908
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This comment has been minimized.
This comment has been minimized.
98fead7 tof33f58cCompare This comment has been minimized.
This comment has been minimized.
chadrik commentedMar 16, 2023
euresti left a comment
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.
This change looks good to me.
| variables= { | ||
| binder.id:argforbinder,arginzip(converter_vars,init_vars) | ||
| } | ||
| init_type=expand_type(init_type,variables) |
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.
The idea behind this change is that a converter should ideally return the same type as the attrs field that it is added to. For example:
deflist_converter(x:Iterable[T])->List[T]:returnlist(x)@attr.s(auto_attribs=True)classA(Generic[T]):x:List[T]=attr.ib(converter=list_converter)
A.x is typeList[T] andlist_converter returnsList[T], and in theory this should always be the case for converters, since their purpose is to convert the init arg to the type of the field. In my changes I'm forgoing a complete comparison of the two types, but the assumption tells us that the number and order of TypeVars should be the same. We use that to generate a replacement map which will replace the converter's broken typevars, with typevars that work within the class's context.
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.
(I assume thedef int_gen slipped in from another example?)
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.
yep. I fixed the example.
This comment has been minimized.
This comment has been minimized.
1 similar comment
This comment has been minimized.
This comment has been minimized.
According tomypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
chadrik commentedMar 17, 2023
Hi@JukkaL, can you or someone else from the mypy team merge this, please? |
chadrik commentedMar 21, 2023
Hi all, can anyone help me get this one merged? It's approved and all ready to go! |
hauntsaninja left a comment
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!
When creating generic classes using
attrs, converters with type vars are not properly integrated into the generated__init__:This MR fixes the bug by copying type vars from the field/attrib into the type extracted from the converter.