Skip to main content
deleted 8 characters in body
Source Link
JimmyJames
  • 30.9k
  • 3
  • 59
  • 110

From the comments on the question:

[amon] Use Pydantic. Get static typing and JSON Schema validation.

[agolta] Given that both serve the same purpose, using JSON Schema appears to be the more effective approach,

Amon is right here and you would be wise to take this advice. First off, the idea that you must choose between schema validation and pydantic is (as amon notes) a false dichotomy. One of the key features of pydantic is that it can generate a JSON schema from your models. I would go as far as to say that each pydantic model implicitly defines a JSON schema. And to be clear, I don't mean you can create a schema to match your model, pydantic will create one for you from a model. You don't even need to understand much about the rich feature set it provides to get a schema. It's a core aspect of the library. It's what allows, for example, FastAPI to generate a Openapi spec service endpoints automatically.

Don't get me wrong, I've long been a contract-first proponent. I've seen code-first approaches cause a lot of headaches. But pydantic is different: in effect, building a pydantic model is defining a JSON schema.

The other huge advantage to using pydantic is that your pydantic model allows for specifying validation rules that you may not be able to easily represent in JSON schema. For example, you can define a value as decimal in pydantic and you get not only a JSON schema that allows for that, it will automatically validate and convert the input to that type at runtime. Many commonly used types are supported in this way and you can customize.

One thing that it won't do is generate a model from a schema. That could be seen as a limitation but because your schema will generally be less specific than your model, it doesn't really matter that much. If you are really picky about your schema, you can simply generate a schema iteratively as you build your model and tweak it to look the way you like. It's pretty easy to understand what the schema will look like from a pydantic model anyway. I've also found that generating a first-pass pydantic model from an example JSON is an effective use of tools like Github copilot as well when you have a complex structure to define.

Again, amon is right here: save yourself a lot of time and trouble and use pydantic.

From the comments on the question:

[amon] Use Pydantic. Get static typing and JSON Schema validation.

[agolta] Given that both serve the same purpose, using JSON Schema appears to be the more effective approach,

Amon is right here and you would be wise to take this advice. First off, the idea that you must choose between schema validation and pydantic is (as amon notes) a false dichotomy. One of the key features of pydantic is that it can generate a JSON schema from your models. I would go as far as to say that each pydantic model implicitly defines a JSON schema. And to be clear, I don't mean you can create a schema to match your model, pydantic will create one for you from a model. You don't even need to understand much about the rich feature set it provides to get a schema. It's a core aspect of the library. It's what allows, for example, FastAPI to generate a Openapi spec service endpoints automatically.

Don't get me wrong, I've long been a contract-first proponent. I've seen code-first approaches cause a lot of headaches. But pydantic is different: in effect, building a pydantic model is defining a JSON schema.

The other huge advantage to using pydantic is that your pydantic model allows for specifying validation rules that you may not be able to easily represent in JSON schema. For example, you can define a value as decimal in pydantic and you get not only a JSON schema that allows for that, it will automatically validate and convert the input to that type at runtime. Many commonly used types are supported in this way and you can customize.

One thing that it won't do is generate a model from a schema. That could be seen as a limitation but because your schema will generally be less specific than your model, it doesn't really matter that much. If you are really picky about your schema, you can simply generate a schema iteratively as you build your model and tweak it to look the way you like. It's pretty easy to understand what the schema will look like from a pydantic model anyway. I've also found that generating a first-pass pydantic model from an example JSON is an effective use of tools like Github copilot as well when you have a complex structure to define.

Again, amon is right here: save yourself a lot of time and trouble and use pydantic.

From the comments on the question:

[amon] Use Pydantic. Get static typing and JSON Schema validation.

[agolta] Given that both serve the same purpose, using JSON Schema appears to be the more effective approach,

Amon is right here and you would be wise to take this advice. First off, the idea that you must choose between schema validation and pydantic is (as amon notes) a false dichotomy. One of the key features of pydantic is that it can generate a JSON schema from your models. I would go as far as to say that each pydantic model implicitly defines a JSON schema. And to be clear, I don't mean you can create a schema to match your model, pydantic will create one for you from a model. You don't even need to understand much about the rich feature set it provides to get a schema. It's a core aspect of the library. It's what allows, for example, FastAPI to generate a Openapi spec service endpoints automatically.

Don't get me wrong, I've long been a contract-first proponent. I've seen code-first approaches cause a lot of headaches. But pydantic is different: in effect, building a pydantic model is defining a JSON schema.

The other huge advantage to using pydantic is that your pydantic model allows for specifying validation rules that you may not be able to easily represent in JSON schema. For example, you can define a value as decimal in pydantic and you get not only a JSON schema that allows for that, it will automatically validate and convert the input to that type at runtime. Many commonly used types are supported in this way and you can customize.

One thing that it won't do is generate a model from a schema. That could be seen as a limitation but because your schema will generally be less specific than your model, it doesn't really matter that much. If you are really picky about your schema, you can simply generate a schema iteratively as you build your model and tweak it to look the way you like. It's pretty easy to understand what the schema will look like from a pydantic model anyway. I've also found that generating a first-pass pydantic model from an example JSON is an effective use of tools like Github copilot when you have a complex structure to define.

Again, amon is right here: save yourself a lot of time and trouble and use pydantic.

Source Link
JimmyJames
  • 30.9k
  • 3
  • 59
  • 110

From the comments on the question:

[amon] Use Pydantic. Get static typing and JSON Schema validation.

[agolta] Given that both serve the same purpose, using JSON Schema appears to be the more effective approach,

Amon is right here and you would be wise to take this advice. First off, the idea that you must choose between schema validation and pydantic is (as amon notes) a false dichotomy. One of the key features of pydantic is that it can generate a JSON schema from your models. I would go as far as to say that each pydantic model implicitly defines a JSON schema. And to be clear, I don't mean you can create a schema to match your model, pydantic will create one for you from a model. You don't even need to understand much about the rich feature set it provides to get a schema. It's a core aspect of the library. It's what allows, for example, FastAPI to generate a Openapi spec service endpoints automatically.

Don't get me wrong, I've long been a contract-first proponent. I've seen code-first approaches cause a lot of headaches. But pydantic is different: in effect, building a pydantic model is defining a JSON schema.

The other huge advantage to using pydantic is that your pydantic model allows for specifying validation rules that you may not be able to easily represent in JSON schema. For example, you can define a value as decimal in pydantic and you get not only a JSON schema that allows for that, it will automatically validate and convert the input to that type at runtime. Many commonly used types are supported in this way and you can customize.

One thing that it won't do is generate a model from a schema. That could be seen as a limitation but because your schema will generally be less specific than your model, it doesn't really matter that much. If you are really picky about your schema, you can simply generate a schema iteratively as you build your model and tweak it to look the way you like. It's pretty easy to understand what the schema will look like from a pydantic model anyway. I've also found that generating a first-pass pydantic model from an example JSON is an effective use of tools like Github copilot as well when you have a complex structure to define.

Again, amon is right here: save yourself a lot of time and trouble and use pydantic.