You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure this is the issue for typeshed or mypy, but with attrs, unpacking a dict to initialize a subclassed attr instance generates a weird type error or not depending on the position of the double-starred kwargs, where the runtime behavior is completely fine for both cases.
Fixes#4708
Allows for multiple ambiguous **kwarg unpacking in a call -- all ambiguous **kwargs will map to all formal args that do not have a certain actual arg.
Fixes#9395
Defers ambiguous **kwarg mapping until all other unambiguous formal args have been mapped -- order of **kwarg unpacking no longer affects the arg map.
Uh oh!
There was an error while loading. Please reload this page.
🐛 Bug Report
I'm not sure this is the issue for typeshed or mypy, but with
attrs
, unpacking a dict to initialize a subclassed attr instance generates a weird type error or not depending on the position of the double-starred kwargs, where the runtime behavior is completely fine for both cases.To Reproduce
Run
mypy
with the following script:Expected Behavior
There should be no type errors. (Or at least, some different error saying that it cannot validate keys from an arbitrary dict..)
Actual Behavior
When
**
comes first:When
**
comes last:where the runtime results are same.
Q: Are there other ways to initialize a subclassed attr instance from a super-attr instance with its values, instead of using
**attr.asdict()
?Your Environment
python -m mypy test-attr.py
mypy.ini
(and other config files):The text was updated successfully, but these errors were encountered: