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

stricter str validation #52

Merged
merged 4 commits into from Jun 21, 2017

Conversation

Projects
None yet
2 participants
@samuelcolvin
Copy link
Owner

samuelcolvin commented Jun 21, 2017

fix #45

In the end, I thought about this and decided whitelisting things which can be coerced to strings made more sense.

It shouldn't affect performance much as most string-like things will be strings and returned before this logic kicks in.

@codecov

This comment has been minimized.

Copy link

codecov bot commented Jun 21, 2017

Codecov Report

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

@@          Coverage Diff          @@
##           master    #52   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          10     10           
  Lines         694    704   +10     
  Branches      155    157    +2     
=====================================
+ Hits          694    704   +10

@samuelcolvin samuelcolvin referenced this pull request Jun 21, 2017

Closed

Optional typecasting #45

@samuelcolvin samuelcolvin force-pushed the stricter-str branch from ad2fc6a to d92d315 Jun 21, 2017

@samuelcolvin samuelcolvin force-pushed the stricter-str branch 2 times, most recently from 20157bf to 3b1d096 Jun 21, 2017

@Zweedeend

This comment has been minimized.

Copy link

Zweedeend commented Jun 21, 2017

Thank you for the fix. I appreciate it.

However, I still think that "strict by default" would be better. I would expect pydantic to check the types, instead of cleaning the data: If I pass my data to a model, and it doesn't raise a Validation error, I expect my data to be of the right types. I expected Pydantic to more like mypy: a typechecker. Mypy would not allow an int were a str is required.

But maybe I shouldn't complain: dict(Model(**my_data)) will have the right types.

@samuelcolvin

This comment has been minimized.

Copy link
Owner Author

samuelcolvin commented Jun 21, 2017

@samuelcolvin

This comment has been minimized.

Copy link
Owner Author

samuelcolvin commented Jun 21, 2017

oh, I see what you mean now. I'll add StrictStr now.

But I don't want to change the default as I think if as user submits {"telephone": 1234567} it shouldn't throw an error, but rather be processed the same as {"telephone": "1234567"}.

@samuelcolvin samuelcolvin force-pushed the stricter-str branch from 3b1d096 to 8c25581 Jun 21, 2017

@samuelcolvin samuelcolvin force-pushed the stricter-str branch from 8c25581 to 1696858 Jun 21, 2017

@samuelcolvin samuelcolvin merged commit 53ba356 into master Jun 21, 2017

4 checks passed

codecov/project 100% (+0%) compared to bf1c501
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
pyup.io/safety-ci No dependencies with known security vulnerabilities.
Details

@samuelcolvin samuelcolvin deleted the stricter-str branch Jun 21, 2017

@Zweedeend

This comment has been minimized.

Copy link

Zweedeend commented Jun 21, 2017

Nice work 👍

@Gr1N Gr1N referenced this pull request May 2, 2018

Closed

More exotic types #161

@samuelcolvin samuelcolvin referenced this pull request Oct 28, 2018

Closed

Strict mode flag #284

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.