Update validataclass requirement from ~=0.11.0 to >=0.11,<0.13

[dependabot]

Updates the requirements on validataclass to permit the latest version.

Release notes

Sourced from validataclass's releases.

0.12.0

Full changelog

This release adds proper support for type checking with mypy using a custom mypy plugin, and significantly improves the typing of the library in general.

A lot of changes have been made to make this possible. This includes some smaller breaking changes and deprecations. However, most of them are practically irrelevant because they affect edge cases that are unlikely to be found in any real life code or similar.

If you're using or planning to use mypy in your project, you should enable the validataclass mypy plugin. Furthermore, some code changes might be necessary to fix typing issues, especially if you have custom validator classes. Please refer to docs/07-mypy-plugin.md for how to configure the mypy plugin, as well as how to fix common typing issues.

While the mypy plugin is (hopefully) production-ready, keep in mind that it's a complex thing that has not been tested in real life projects yet. There are some known issues and probably several unknown issues, and some features are still missing. Please report any issues or bugs that you encounter using this plugin.

Apart from all this, the release also introduces a new feature to optionally reject unknown fields in validataclasses with validation errors.

Finally, this version drops support for Python 3.8 and 3.9 and adds support for Python 3.13 and 3.14.

Added

• Add support for Python 3.13. #132
• Add support for Python 3.14. #137
• Add mypy plugin for type checking validataclasses with mypy. #140, #141
  • Please note that the mypy plugin needs to be enabled explicitly in your mypy configuration!
  • See docs/07-mypy-plugin.md for details on how to enable and configure the plugin.
• Add option to reject unknown fields in validataclasses (by [@​the-infinity]). #139
  • The new option reject_unknown_fields can be set both in the @validataclass decorator and the DataclassValidator.
  • If this option is True, the DataclassValidator will reject unknown fields with a field_not_allowed error. This is the same validation error used by the RejectValidator.
  • When the option is set both in the @validataclass decorator and in the DataclassValidator, the option of the DataclassValidator takes precedence. It's recommended to use the decorator option to define the default behavior for a specific validataclass, and the validator option to override this behavior, e.g. for debugging purposes.

Changed

Note: Many of the following changes can be considered breaking changes to some degree. However, it is unlikely that any of them affects any real life code. The most notable change is the first one, but it primarily concern typing and should not break any existing code. It's still advised to take a closer look at them when updating.

• Generic-based typing for validator classes. #134
  • The validator base class Validator is now a generic class with one type parameter. This type parameter specifies the type of the output of this validator: Given a validator of type Validator[T], the return type of validator.validate() must be T. This does not relate to the type of input data.
  • For example, the DecimalValidator is of type Validator[Decimal] because it always returns a Decimal object.
  • Validator classes can have their own type parameters as well. For example, the ListValidator has a type parameter to indicate the type of items in the returned list: ListValidator[T] inherits from Validator[list[T]], it requires an item validator of type Validator[T] and always returns a list[T].
  • In most cases, type parameters will be automatically inferred from the construction arguments, e.g. when using ListValidator(StringValidator()) in a validataclass, its type will be inferred as ListValidator[str]. However, there are some edge cases where type inference doesn't always work (e.g. for DictValidator). In those cases, mypy might report an error. A possible solution is to define the validator as a variable outside the validataclass and annotate it explicitly, although the more convenient option is to just add a # type: ignore for this validator. This problem might be solved in a future version.
  • There can be typing problems when inheriting from another validator and changing its output type (e.g. implementing the DecimalValidator as a subclassed StringValidator will result in typing errors). Please refer to the docs.
  • The base classes for several validators have been changed for correct typing (see previous point). This also implies that attributes from base validators (e.g. min_length from StringValidator) might not be accessible directly anymore. In general, you should not rely on the existence or names of attributes in validator classes.
• Generic-based typing for default objects. #136
  • Default classes (e.g. Default, DefaultFactory) all inherit from a new generic base class BaseDefault[T] now, where T specifies the type of the actual default value. (Previously, Default was the base class, which was problematic for several reasons.)
  • The classes Default[T] and DefaultFactory[T] are generic as well, specifying the type of their output value.
• DefaultUnset is now simply an alias for Default(UnsetValue) rather than a special subclass. #136
  • As a side effect, its string representation (repr(DefaultUnset)) has changed to Default(UnsetValue).
  • Also, DefaultUnset is not unique anymore. Use == rather than is to check if something is DefaultUnset.
• The default parameter of validataclass_field() is keyword-only now, to be consistent with dataclasses.field(). #140
• Validator: The helper method _ensure_type() now allows None if NoneType is in the list of expected types. #134
• Several error messages have been changed for consistency. This usually shouldn't have any effect on code.

... (truncated)

Changelog

Sourced from validataclass's changelog.

0.12.0 - 2026-04-14

Full changelog

This release adds proper support for type checking with mypy using a custom mypy plugin, and significantly improves the typing of the library in general.

A lot of changes have been made to make this possible. This includes some smaller breaking changes and deprecations. However, most of them are practically irrelevant because they affect edge cases that are unlikely to be found in any real life code or similar.

If you're using or planning to use mypy in your project, you should enable the validataclass mypy plugin. Furthermore, some code changes might be necessary to fix typing issues, especially if you have custom validator classes. Please refer to docs/07-mypy-plugin.md for how to configure the mypy plugin, as well as how to fix common typing issues.

While the mypy plugin is (hopefully) production-ready, keep in mind that it's a complex thing that has not been tested in real life projects yet. There are some known issues and probably several unknown issues, and some features are still missing. Please report any issues or bugs that you encounter using this plugin.

Apart from all this, the release also introduces a new feature to optionally reject unknown fields in validataclasses with validation errors.

Finally, this version drops support for Python 3.8 and 3.9 and adds support for Python 3.13 and 3.14.

Added

• Add support for Python 3.13. #132
• Add support for Python 3.14. #137
• Add mypy plugin for type checking validataclasses with mypy. #140, #141
  • Please note that the mypy plugin needs to be enabled explicitly in your mypy configuration!
  • See docs/07-mypy-plugin.md for details on how to enable and configure the plugin.
• Add option to reject unknown fields in validataclasses (by [@​the-infinity]). #139
  • The new option reject_unknown_fields can be set both in the @validataclass decorator and the DataclassValidator.
  • If this option is True, the DataclassValidator will reject unknown fields with a field_not_allowed error. This is the same validation error used by the RejectValidator.
  • When the option is set both in the @validataclass decorator and in the DataclassValidator, the option of the DataclassValidator takes precedence. It's recommended to use the decorator option to define the default behavior for a specific validataclass, and the validator option to override this behavior, e.g. for debugging purposes.

Changed

Note: Many of the following changes can be considered breaking changes to some degree. However, it is unlikely that any of them affects any real life code. The most notable change is the first one, but it primarily concern typing and should not break any existing code. It's still advised to take a closer look at them when updating.

• Generic-based typing for validator classes. #134
  • The validator base class Validator is now a generic class with one type parameter. This type parameter specifies the type of the output of this validator: Given a validator of type Validator[T], the return type of

... (truncated)

Commits

• 9de429c GitHub Actions: Fix release workflow
• fed6ccd Merge pull request #145 from binary-butterfly/prepare-release-0.12.0
• 3d06c64 Prepare release of 0.12.0
• f800490 GitHub Actions: Remove dev-mypy branch from test workflow
• 6c58904 Merge pull request #139 from binary-butterfly/prevent-additional-properties
• 330bb38 Update src/validataclass/dataclasses/validataclass.py
• 290dbb3 make parameter explicit
• 15ae000 docs and improvements
• 64ca2f7 update docs with updated exceptions UnknownFieldsError -> DictFieldsValidatio...
• 992cbca use DictValidator.default_validator with RejectValidator instead of own logic...
• Additional commits viewable in compare view