Strict configuration

[maxrothman]

Feature request: strict mode configuration flag

This issue has been a sensitive one in the past, so I'm trying to tread lightly here. Pydantic's position so far has been that because it's a parsing, not a validation library, fields should coerce their values to the specified type if possible (e.g. a field type-hinted with float given "1" coerces it to 1), and that Strict* fields (e.g. StrictFloat, StrictBool, …) are available if users prefer to use them. Requests for a way to make default types behave strictly have been closed due to implementation concerns.

However, the codebase has evolved significantly since #578, #360, and #284 were closed, and I think that some of the earlier difficulties in building this feature are no longer present today.

In #284, the reason given for not including a strict mode config was that pydantic would no longer be able to just call float(x) and pass the errors along, and that there are edge cases around bools and ints. But in 4f4e22e, the validator for float types became validators.float_validator() rather than float(), strict_int_validator() was added in 1b467da and distinguishes between bools and ints, and on master, float_validator() actually does extra work compared to strict_float_validator() to accept non-float values.

As far as I can tell, the only thing required to implement this flag now would be to build validators._VALIDATORS conditionally for each model based on a config value, using the strict_* validators rather than the standard ones when the flag was set.

There are several different ways this feature could be implemented: as a global flag, as another property on the model config, etc. I don't have strong opinions on this topic, since in my code I would probably enable this configuration universally.

Thoughts? The lack of this feature is the only thing keeping me from strongly recommending the use of Pydantic in my workplace, and it's clearly a feature that others are interested in having as well, as evidenced by the prior requests. I would be interested in contributing a PR for this change if you're interested in pursuing it.

[dmontagu]

Could you describe the use case you have in mind for this feature? I'm trying to understand whether your goal is closer to using it for runtime type-checking when instantiating BaseModel subclasses, or if it is specific to the parsing process (e.g., you always want to raise errors when parsing a json payload containing "1.0" instead of 1.0).

---

I would be in favor of supporting this if we could come up with a simple implementation with minimal impact on existing logic. I can't tell right now from just thinking about it whether I think the approach you have described would meet the bar in terms of simplicity; @samuelcolvin might have different opinions.

---

One other possible approach might be to introduce a generic type called Strict that specifically just adds an issubclass check. We could probably tweak the mypy plugin so that Strict[MyType] is treated by mypy as an alias for MyType. (It would still make sense to keep StrictInt and StrictFloat since they offer constraint functionality.)

[maxrothman]

My use case is that I'm planning on using Pydantic's JSON Schema integration to autogenerate clients for my frontend applications. In that setup, it should theoretically be impossible for my backend to receive "1.0" instead of 1.0, so if it does, it indicates that there's a weird bug in the frontend, and I want it exposed quickly and loudly.

I'm not a huge fan of the Strict generic type approach, because I'd still have to wrap it around the types for all of my fields. I'd rather set a global config flag or set a class-level flag on a base class and inherit from it.

Sounds like you're at least open to seeing a PR? Since you indicated others might have differing opinions, I'll wait a few days, and if nothing changes, I'll give it a shot and we can go from there?

[dmontagu]

For what it's worth, I think you could implement what you are describing through the use of a shared base class:

from typing import Any, Type, Callable
from pydantic import BaseModel


class PossiblyStrictModel(BaseModel):
    def __init_subclass__(cls):
        if getattr(cls.__config__, "strict", False):
            def __init__(__pydantic_self__, **data: Any) -> None:
                for k, v in data.items():
                    field = __pydantic_self__.__fields__[k]
                    if not isinstance(v, field.type_):  # not right for container types
                        raise TypeError(f"Received argument {v!r} of incorrect type for field {field}")
                super().__init__(**data)
            cls.__init__ = __init__


class Model(PossiblyStrictModel):
    a: int
    class Config:
        strict = True

Model(a=1)
Model(a="1")  # error; stops erroring if you set Config.strict = False

I'm not super excited about the prospect of officially supporting this in pydantic because 100% correctness would probably come with a large number of edge cases to test, and an on-going burden of ensuring both approaches work for every possible field type.

I'm certainly open to seeing a PR, I just think acceptance would be dependent on reaching a relatively high bar of simplicity in order to ensure it doesn't increase the on-going maintenance burden, and doesn't result in discouraging future feature work because of backwards compatibility challenges. If you want to take a shot, I'll review it. @samuelcolvin tends to have strong opinions on these sorts of issues though so you might want to wait for his response first.

[samuelcolvin]

Hi, sorry for not replying earlier. Thanks for submitting the request and taking the time to explain why you need it.

I'm basically pro implementing this if it's possible for the following reasons:

• people want the feature. Too many open source projects get supercilious about refusing what they perceive to be "bad" feature requests, while ignoring that people wanting a feature is a reason in itself, e.g. Single quotes option psf/black#118.
• it would resolve the confusion and resulting caveats about what pydantic is/does.
• I'm intending to work on a type checking decorator as per type checking decorator #347, and to me it would be very confusing if a type checking decorator silently coerced arguments.

One point where I think you're incorrect @maxrothman is that validating an input to a float field, does just call float(v) inside float_validator that hasn't changed significantly for a long time.

In terms of implementation, I think the simplest solution would be to simply call isinstance() before all values are validated. I think that would be simpler to implement, reason with and maintain than switching validators._VALIDATORS.

We'd need to store the expected type on a field, and might need some special logic for cases like booleans, but I think that's doable.

This would make strict mode slightly slower than normal mode, but I think that's bearable, if that becomes a problem I can think of a number of ways of working around it.

In terms of a switch to enable this, I think a config flag would be the easiest solution, we could even have a StrictBaseModel class which just sets that config flag.

Thoughts?

[Pastromhaug]

I'm going to second that having a strict mode would be very useful. I would like to default to strict while allowing certain type coercions when specified.

To illustrate, yesterday I spent some time debugging a unit test that was broken in a non-obvious way. It turned out that Pydantic was coercing a UUID to an int 😐. In practice, we almost always know exactly what the type should be and would like to enforce that.

[samuelcolvin]

For the foreseeable future (at least until another major release) strict mode will not be the default. But usage should be as simple as changing your import to from pydantic import StrictBaseModel as BaseModel.

[maxrothman]

@samuelcolvin thank you for being open to this proposal! Your approach towards this ("bad") request is an exemplar of great open source management.

I'm not sure I understand how the isinstance checks of "strict mode" would be slower than the default mode, most of the validators already call isinstance. Am I missing something?

---

Having given this a little more thought, I've realized a slight problem in the straight-up "isinstance" approach: it'll result in a worse dev experience when deserializing complex objects (e.g. datetimes). To pass the isinstance check, you'd have to deserialize the datetime before passing it to the model, losing the benefits of Pydantic's unified approach to validation. I suspect this is why @Pastromhaug suggested allowing certain coercions.

To fix that, I think we need a split interface: one for instantiating model instances internally, and one for deserializing external data.

The deserialization API would be strict-ish, in that the wire-types of certain Python types would be the same type in JSON. For example UUID and str would both be represented as JSON strings. The key difference is that there'd be only 1 valid (de)serialization for each type, such that the following invariant holds:

forall x: x == serialize(deserialize(x))

This could mostly be implemented by using the existing strict_* validators and basic isinstance checks, but there'd be some special cases to sort out. For example, datetimes currently accept multiple formats, which would break the above invariant. Defaulting to a specific format (probably ISO-8601) would resolve the issue (the format could be overridable somehow, maybe via Field()).

There's already a parse_obj method on models, I think it'd be a natural fit for this deserialization API.

The interface for instantiating instances internally could just be __init__. I'd even potentially support doing no runtime typechecking in this interface, since mypy should be able to do it statically. If people wanted to do runtime typechecking, it could be added via a separate feature, such as the decorator @samuelcolvin's proposed.

---

With all that out of my brain, here's my proposal:

Add a strict flag to model config. This flag changes the behavior of BaseModel.__init__ and BaseModel.parse_obj (or enables some other method, I'm not married to the parse_obj part).

• __init__: disables coercion, this method becomes a dumb constructor
• parse_obj: performs strict deserialization, such that forall json_value, Model: json_value == Model.parse_raw(json_value).json

Some method is built to deal with types that have multiple useful serializations. Looking through _VALIDATORS, only the datetime types seem to be the issue, so it might be easy enough to just add a format parameter to Field().

[dmontagu]

I'm not sure I understand how the isinstance checks of "strict mode" would be slower than the default mode, most of the validators already call isinstance

I think @samuelcolvin's point is that the isinstance checks would be run in addition to all the usual validation checks, so it would be strictly slower.

[dmontagu]

To fix that, I think we need a split interface: one for instantiating model instances internally, and one for deserializing external data.

This awkwardness has come up various times recently. I think the problem boils down to different "degrees" of desired parsing, and the fact that there are a huge number of edge cases and desired behaviors to handle if you try to go beyond "parse everything" and "parse nothing".

For what it's worth, if you are "instantiating model instances internally", there is the BaseModel.construct method which will perform no validation whatsoever, and I've personally seen it run >30x faster than BaseModel.__init__ even for small models (with some nested lists and dicts).

---

__init__: disables coercion, this method becomes a dumb constructor

This was the reason that BaseModel.construct was created, and is probably a better fit for this case if you are trying to accomplish disabled validation for performance reasons.

(For what it's worth, I totally think it would make sense to offer runtime type-checking of BaseModel.construct via config flag during testing, and it could be done in the metaclass to ensure zero runtime cost if not used, but that's a separate feature request. If anyone wants it please open an issue!)

---

I could see an argument being made for having a config setting that lets you toggle whether __init__ behaves more like parse_obj or more like construct. In practice, I think this could amount to having a config settings for disabling the "default" (i.e., for built-in types, or pydantic-provided) and/or "custom" validators (i.e., user defined using @validator) in calls to __init__.

This would retain the ability to use custom validators to parse missing fields, perform non-idempotent transformations, etc., and would make it easy to turn on the usual validators for testing, but would also let you get closer to raw BaseModel.construct speed in production by disabling the "default" validations via config where you are confident it is safe due to your testing.

[maxrothman]

Oh, I didn't know about BaseModel.construct.. Is it type-checkable by mypy? If so, then it definitely serves the role I intended for __init__ in my proposal. I don't have strong feelings about what __init__ actually does, I'm more concerned about the separation between the two, which it seems like already exists.

---

My proposal again, but edited taking the above into account:

Add a strict flag to model config. This flag changes the parsing behavior of BaseModel (whether in __init__, parse_obj, or otherwise; I don't have strong feelings about the interface).

The parsing behavior would be altered to perform strict deserialization, such that forall json_value, Model: json_value == Model.parse_raw(json_value).json

Some method is built to deal with types that have multiple useful serializations. Looking through _VALIDATORS, only the datetime types seem to be the issue, so it might be easy enough to just add a format parameter to Field().

[dmontagu]

Yes, it can be properly type checked, but you have to use the pydantic mypy plugin (I believe the latest release still requires the use of mypy 0.740; hopefully we can push a new release soon to be compatible with latest).

Docs here.

[samuelcolvin]

I'm pretty opposed to changing the behaviour of __init__, even via a config flag.

I think one of the reasons pydantic is popular is that for many cases it "just works" - it's also (I think) relatively easy to use for inexperienced developers. I'm opposed to changes which increase the cognitive burden of getting started with pydantic, even if it helps some people.

Looking through _VALIDATORS, only the datetime types seem to be the issue

I'm afraid that's not the whole story, there's also all the custom pydantic types, I count 33 there. Each would need consideration, tests and in some cases modification.

---

I think to keep things simple we should have two modes:

1. The current "coercion inclined" mode. With strict types when you want to constrain things.
2. A new "strict" mode (used via StrictBaseModel), where all type checks are "hard", e.g. use isinstance(v, field_type) or in some cases v.__class__ == field_type

Then we add two generic types (or at least types that can be parameterised as Json can now):

• Strict[], usage: Strict[int], equivalent of StrictInt, which can be used in "coercion inclined" mode to make a field strict - I think this was discussed somewhere but I can't find the issue right now.
• Coerce[], usage: Coerce[int], equivalent of int in normal mode, which can be used in strict mode to disable the strict check and therefore act like pydantic does now.

Does that make sense?

@dmontagu do you think Strict[] and Coerce[] can me made to play nicely with mypy via the plugin (or perhaps without the plugin)?

@koxudaxi do you think Strict[] and Coerce[] can me made to play nicely with pycharm via the plugin?

There are still some weird cases like AnyUrl, where I imagine people would expect a string to work, but technically strict mode would refuse a string since it's not an instance of AnyStr, do we make a few exceptions even in strict mode for things like this?

---

If you want a way to parse datetime's from ISO-8601 strings but nothing else, either:

• you can implement your own custom type
• or we could add a IsoDateTime type to pydantic, please create a separate issue

[dmontagu]

@samuelcolvin I agree with the point about having it "just work", not to mention how much pain would be involved in migrating if we fundamentally changed the behavior of __init__ 😄.

---

I'm fine with the idea of StrictBaseModel and Strict/Coerce.

In some ways I think it could actually simplify the mypy plugin, potentially allowing us to remove the "strict" config setting since it would be specified on the actual object.

That said, I also think it would be a substantial amount of work to get it working with mypy, but probably not more than it would take to carefully and correctly implement the feature anyway.

[koxudaxi]

@samuelcolvin
I think great to treat StrictBaseModel Strict/Coerce with the pycharm plugin.
Because the plugin can inspect values, and type-checking comfortable with theses class.

I agree with your thoughts. I desire pydanitc is a simple design.
I'm afraid to decrease the performance of the plugin by individual cases.

BTW, I feel Coerce is a problematic word on non-native English speakers. I know type coercion is ordinary words in computer science.
I guess a lot of people use Python and Pydantic, who might not export. Also, I understand a lot of non-native English speakers use Pydanitc.

Of course, I know Cast is not a perfect word choice.
If It is implemented as Coerce then, we should write documents easy to understand everyone.