Django-pydantic-field

Enforced null checks for SchemaField
In the example below, typing linters should enforce type compatibility:
python
class BuildingMeta(pydantic.BaseModel):
type: Optional[BuildingTypes]

class Building(models.Model):
opt_meta: BuildingMeta = SchemaField(default={"type": "frame"}, null=True)
meta: Optional[BuildingMeta] = SchemaField(default={"type": "frame"})


Pyright will complain on both fields:

sample_app/models.py:5:32 - error: Expression of type "BuildingMeta | None" cannot be assigned to declared type "BuildingMeta"
sample_app/models.py:6:40 - error: Expression of type "STSchemaField" cannot be assigned to declared type "BuildingMeta | None"


Mypy has more broaden resolution for latter check, but still be able to recognise first one:

sample_app/models.py:5: error: Incompatible types in assignment (expression has type "Optional[BuildingMeta]", variable has type "BuildingMeta")


Fixing field annotations will resolve issues on both checkers:
python
class Building(models.Model):
opt_meta: Optional[BuildingMeta] = SchemaField(default={"type": "frame"}, null=True)
meta: BuildingMeta = SchemaField(default={"type": "frame"})

The check also enforces `default=None` to have `null=True` param.

Relaxed restrictions on `default=` argument
In addition to null enforcement, typing checks allow arbitrary values for `default=` argument, as long as they are acceptable for pydantic's `BaseModel.parse_obj` method. Callables are also accepted, mimicking Django's field semantics.

**Full Changelog**: https://github.com/surenkov/django-pydantic-field/compare/v0.1.10...v0.1.11

Slightly improve inheritance chain, better typings for `SchemaField` factory function.

**Full Changelog**: https://github.com/surenkov/django-pydantic-field/compare/v0.1.9...v0.1.10

What's Changed
* Attempt to defer ForwardRefs resolution by surenkov in https://github.com/surenkov/django-pydantic-field/pull/5


**Full Changelog**: https://github.com/surenkov/django-pydantic-field/compare/v0.1.8...v0.1.9

Django model fields are required to throw `django.core.exceptions.ValidationError` during `.to_python(value)` call.
Let's stick to that recommendation.

> Convert the input value into the expected Python data type, raising
> django.core.exceptions.ValidationError if the data can't be converted.

I believe that initially introduced `error_handler=` param is basically doesn't make sense, as it breaks regular validation flow and could be even harmful, as by default it simply suppress errors and writes them in logging. (Re)raising validation errors would be more explicit alternative to that.