-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Add support for converters with TypeVars on generic attrs classes #14908
Conversation
This comment has been minimized.
This comment has been minimized.
98fead7
to
f33f58c
Compare
f33f58c
to
531f724
Compare
This comment has been minimized.
This comment has been minimized.
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: arg for binder, arg in zip(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:
def list_converter(x: Iterable[T]) -> List[T]:
return list(x)
@attr.s(auto_attribs=True)
class A(Generic[T]):
x: List[T] = attr.ib(converter=list_converter)
A.x
is type List[T]
and list_converter
returns List[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 the def 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.
f0d3212
to
54d582d
Compare
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Hi @JukkaL, can you or someone else from the mypy team merge this, please? |
Hi all, can anyone help me get this one merged? It's approved and all ready to go! |
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.