-
-
Notifications
You must be signed in to change notification settings - Fork 395
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
SelectField should not coerce None into string "None" #289
Comments
Same Issue, i add optional validators to my SelectField, so i received a None type value and it's coerced to 'None' string Value. Which is a nonsense. We cannot know anymore whether a value has been introduced unless we check again with choices. |
Same here. I tried to use a InputRequired works fine, so I'm using that now (and arguably should have been from the start), but it still feels like using DataRequired shouldn't be a problem. |
Hi, same here too SelectField + Optionnal() validator + do not add this Simple workaround is to set See also: |
Pull request #288 was just merged. |
Any plan to update pypi version? @georgschoelly |
@alswl I'm not the one making releases. Maybe open a new issue? |
Também correção do alinhamento bootstrap
Também correção do alinhamento bootstrap
Had this behaviour been rolled back or is there a reason why I still get the wrong conversion of None to 'None' with version 3.0.1 ? |
I've stumbled upon weird behavior where a SelectField could have the value
"None"
instead of one of the choices and I'm not the only one having encountered this. Example:which results in:
What happened?
SelectField
coerced the field's default valueNone
to"None"
. I would expect it to beNone
.Additionally to unexpected, this is inconsistent with other types. E.g.
SelectField(coerce=int)
givesNone
as expected.Details
The relevant code is in
fields/core.py
:Strangely, this behavior is documented by one of the tests:
The commit adding the test 880e98a does not explain why this behavior would be correct. Additionally, another test f6d8c75 kinda relies on this behavior, but looking at it, I would not say that this is correct behavior. (Namely,
bool("None") -> True
instead ofbool(None) -> False
.Proposed fix
First of all, this would change the API slightly, but I don't think this is a problem. As it currently stands, its a bug that is not obvious.
None
and"None"
look exactly the same when printing them, but becausebool(None) != bool("None")
this easily lead to unexpected behavior.My proposed fix tests for
None
, but we could also usedefault=unset_value
instead ofdefault=None
in the constructor and test for that. Or alternatively, instead of usingstr
as the default coercion, we could use an identity function that raises if the value is not a string already.The changes are in pull request #288.
The text was updated successfully, but these errors were encountered: