-
-
Notifications
You must be signed in to change notification settings - Fork 6.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
feat: enforce Decimal type in min_value and max_value arguments of DecimalField #8972
Conversation
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 am wondering if this enforcement create some noise or might break existing codes which were not using float and decimal in right separation? in that case should we also improve the docs if / where necessary
I think the change may "break" the code but actually is fixing bugs on projects in which those input arguments are not decimal types. |
My preference would be to trigger a warning for now and put this through the deprecation cycle. We previously allowed floats, ints, and Decimals and now we are only allowing Decimal. I definitely agree with the goal, but breaking it immediately is probably not the right move. |
I think we should keep supporting Int, float & decimal all. and we should mostly align with django first |
I agree with that a first step should be warn the situation instead of break. The point of @auvipy about aligning with Django is also interesting, because actually a [Min|Max]ValueValidator with any number type can be added to a models.DecimalField. Thus, do you agree guys to only leave a warning message in this PR? |
oh I see I miss read it. decimalField should support decimals only. but as it might break existing codes, we should only start with the warning for now :) |
we should move towards the path of django but also provide the users a graceful way to fix their code |
@auvipy done! I also included a test. |
It looks like this finally got released, so sorry for the delay, but this really should have used warnings instead of logging a warning. We run our tests flagging warnings as errors, but I just happened to see this in the logs and it was less obvious than it could have been to track down where this was coming from. I assume this is really only a problem when using |
Description
Fixes issue #8963