-
Notifications
You must be signed in to change notification settings - Fork 77
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 warning about the limitations of type inference when using Final #151
Conversation
368d35e
to
5d3e1c1
Compare
I think the behavior of #150 is ok... Of course you cannot get a complete type definition from just a single value, but using |
…ng Final" This reverts commit 1dec7d5.
marshmallow_dataclass/__init__.py
Outdated
"Support for type inference from a default value is limited and may " | ||
"result in inaccurate validation. Provide a type to Final[...] to " | ||
"ensure accurate validation." |
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.
Given this message, it will not be obvious where the issue comes from. I thing the warning should mention that it comes from marshmallow_dataclass, the name of the type, and the name of the field.
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.
Agreed. I've pushed a new commit, but I don't know how to get the name of the field. Is there a way to get it from within field_for_schema(...)
?
I've added a warning about the limitations of using a default factory according to our discussion in #152. |
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 and sorry for the delay !
No worries, thanks for merging the PR! 🙂 |
Unfortunately, I implemented type inference from a default value when using
Final
incorrectly in #150, i.e. it only works for simple cases, but it's actually not true type inference. I'm not sure whether it's currently possible to get the type hint inferred from the default value at runtime.E.g.:
dataclasses.field(...)
, but this could be fixed.list
but cannot inferList[Union[int, str]]
. In order to get the correct type, actual type inference is be needed.This PR changes the behavior, so that a
NotImplementedError
is raised whenFinal
has no argument and a default value exists. I don't think it's a big problem to not support this case because type inference is just a convenience. Instead,Final[...]
could always be typed explicitly.Sorry for the sloppiness in #150 ...