Skip to content
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

Make bool_validator strict #617

Merged
merged 15 commits into from Aug 10, 2019
Merged

Make bool_validator strict #617

merged 15 commits into from Aug 10, 2019

Conversation

@dmontagu
Copy link
Collaborator

dmontagu commented Jun 23, 2019

Change Summary

Make bool_validator a little more strict, in line with #579

In particular, allow True, False, 1, 0, all yaml true/false strings, the strings 't'/'T'/'f'/'F' (following DRF), and the bytes versions of those strings. Anything else raises a ValidationError.

Also adds RelaxedBool to retain current functionality if desired.

Related issue number

#579


Reviewing the discussion in #579, it wasn't clear to me whether the goal was to modify StrictBool to allow these strings, or to change bool_validator. My current interpretation is that the goal was to change bool_validator to bring it in line with more expected/useful behavior in a non-python context. If that's wrong, I'd be happy to refactor so that this logic applies to StrictBool instead.

This would be a breaking change for a very common type (if modifying bool_validator anyway), so I wouldn't necessarily expect it to be merged prior to a 1.0 release, but figured I'd start the process.


Checklist

  • Unit tests for the changes exist
  • Tests pass on CI and coverage remains at 100%
  • Documentation reflects the changes where applicable
  • HISTORY.rst has been updated
    • if this is the first change since a release, please add a new section
    • include the issue number or this pull request number #<number>
    • include your github username @<whomever>
pydantic/validators.py Outdated Show resolved Hide resolved
@codecov

This comment has been minimized.

Copy link

codecov bot commented Jun 23, 2019

Codecov Report

Merging #617 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #617   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          15     15           
  Lines        2710   2718    +8     
  Branches      532    534    +2     
=====================================
+ Hits         2710   2718    +8
Copy link
Owner

samuelcolvin left a comment

Otherwise I'm happy with this.

@cazgp, you created the issue. Feedback here welcome.

pydantic/validators.py Outdated Show resolved Hide resolved
pydantic/validators.py Outdated Show resolved Hide resolved
@cazgp

This comment has been minimized.

Copy link
Contributor

cazgp commented Jun 26, 2019

Thanks for this!

@dmontagu dmontagu force-pushed the dmontagu:strictbool branch from 3988844 to 4a46f2f Jun 27, 2019
@dmontagu

This comment has been minimized.

Copy link
Collaborator Author

dmontagu commented Jun 28, 2019

@samuelcolvin I've updated the docs. However, I still have two questions:

  1. should I update the history? I'm not sure if the goal is to include this in an upcoming 0.x release or wait for 1.0
  2. I only made note of the change in the section of the docs about StrictBool and RelaxedBool. I think this is okay, but given this is a breaking change to the behavior of bool, should a note be placed somewhere else as well?
@lgtm-com

This comment has been minimized.

Copy link

lgtm-com bot commented Jun 28, 2019

This pull request introduces 1 alert when merging fc41a25 into ccdf8e1 - view on LGTM.com

new alerts:

  • 1 for Module-level cyclic import
@lgtm-com

This comment has been minimized.

Copy link

lgtm-com bot commented Jun 28, 2019

This pull request introduces 1 alert when merging 1a73534 into ccdf8e1 - view on LGTM.com

new alerts:

  • 1 for Module-level cyclic import
Copy link
Owner

samuelcolvin left a comment

Looking pretty good, RelaxedBool seems good.

See #576 (comment) for discussion on how we deal with history/releases.


If you want more permissive behavior, ``RelaxedBool`` can be used to cast values to bool using standard python logic.
For example, ``None`` would be cast to False. Note that this behaves differently than the standard ``bool`` field
for some values: for example, a ``RelaxedBool`` field would cast the string "false" to True.

This comment has been minimized.

Copy link
@samuelcolvin

samuelcolvin Jun 28, 2019

Owner
Suggested change
for some values: for example, a ``RelaxedBool`` field would cast the string "false" to True.
for some values: for example, a ``RelaxedBool`` field would cast the string ``"false"`` to ``True``.
docs/index.rst Show resolved Hide resolved
pydantic/validators.py Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
@samuelcolvin samuelcolvin mentioned this pull request Jun 28, 2019
3 of 5 tasks complete
@dmontagu dmontagu force-pushed the dmontagu:strictbool branch 3 times, most recently from 7dc18d0 to e0bfe47 Jul 10, 2019
@dmontagu dmontagu force-pushed the dmontagu:strictbool branch 2 times, most recently from 21c28d8 to 773e160 Jul 23, 2019
@samuelcolvin samuelcolvin added this to the Version 1 milestone Aug 5, 2019
@samuelcolvin

This comment has been minimized.

Copy link
Owner

samuelcolvin commented Aug 6, 2019

please can you rebase and move the history change to changes/ as per #719.

@dmontagu dmontagu force-pushed the dmontagu:strictbool branch from 773e160 to 46697bb Aug 7, 2019
HISTORY.rst Outdated Show resolved Hide resolved
docs/examples/exotic.py Outdated Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
pydantic/errors.py Outdated Show resolved Hide resolved
@@ -243,6 +244,21 @@ def validate(cls, value: str) -> str:
return validate_email(value)[1]


class RelaxedBool(int):

This comment has been minimized.

Copy link
@samuelcolvin

samuelcolvin Aug 8, 2019

Owner

humm, I'm not sure Relaxed is a good choice of word.

I personally think this type is very wierd and people shouldn't use it since it makes absolutely zero sense to parse 'false' to False.

I think either we should:

  • rename it to something like StandardLibBool and recommend against using it
  • or, (better in my opinion) remove it altogether. Please can implement it themselves if they really want it.

This comment has been minimized.

Copy link
@dmontagu

dmontagu Aug 8, 2019

Author Collaborator

I think the only reason to use it would be performance; right now if you want speed when you know you are getting the right type, it's awkward. But I agree it would be better if the name reflected this.

Actually I guess the default validator is pretty fast if it is already the right type?

I'd be okay either dropping or giving a different name. (I'll keep my commits locally for when someone asks for it 😈)

This comment has been minimized.

Copy link
@samuelcolvin

samuelcolvin Aug 8, 2019

Owner

okay, let's keep it but say that in the docs.

This comment has been minimized.

Copy link
@dmontagu

dmontagu Aug 8, 2019

Author Collaborator

@samuelcolvin I did some minor investigation of the timing and I think the speed difference between the two bool validators is negligible (when the inputs are bools); in my runs I didn't see a clear winner.

I think probably the only real world use case where it might really be helpful is if you wanted to accept a custom type as a field input and had a custom __bool__ implementation.

At any rate, based on the above I can't think of anything worth saying in the docs except that it follows built-in python logic for boolean casting (what they currently say). Let me know if you still disagree, or if this changes your mind back to wanting to remove RelaxedBool.

This comment has been minimized.

Copy link
@samuelcolvin

samuelcolvin Aug 8, 2019

Owner

I would say let's remove it then. Nothing to stop people implementing it themselves if they really want it. But we we think there's basically no context in which you should use it, it shouldn't be added.

Sorry to flip flop.

pydantic/validators.py Show resolved Hide resolved
tests/test_types.py Show resolved Hide resolved
David Montague and others added 4 commits Aug 7, 2019
Co-Authored-By: Samuel Colvin <samcolvin@gmail.com>
Co-Authored-By: Samuel Colvin <samcolvin@gmail.com>
Co-Authored-By: Samuel Colvin <samcolvin@gmail.com>
@dmontagu dmontagu force-pushed the dmontagu:strictbool branch from eab3ffc to ecd6ec1 Aug 8, 2019
David Montague and others added 4 commits Aug 8, 2019
David Montague
David Montague
@samuelcolvin samuelcolvin merged commit 72edca7 into samuelcolvin:master Aug 10, 2019
10 checks passed
10 checks passed
Header rules No header rules processed
Details
Pages changed 3 new files uploaded
Details
Redirect rules No redirect rules processed
Details
Mixed content No mixed content detected
Details
codecov/project 100% (+0%) compared to e6c44ee
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details
samuelcolvin.pydantic Build #20190810.1 succeeded
Details
samuelcolvin.pydantic (Job Python36) Job Python36 succeeded
Details
samuelcolvin.pydantic (Job Python37) Job Python37 succeeded
Details
@samuelcolvin samuelcolvin mentioned this pull request Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.