Skip to content

Latest commit

 

History

History
766 lines (525 loc) · 40.6 KB

File metadata and controls

766 lines (525 loc) · 40.6 KB

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

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 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.

Deprecated

The following things have been deprecated and might be removed in a future version (possibly the next minor release).

  • Deprecate calling DefaultUnset() and NoDefault(). #136
    • You should use them without parentheses instead: DefaultUnset and NoDefault.
  • validataclass_field(): Deprecate using the default argument with "raw" values and dataclasses.MISSING. #140
    • Currently, you can use "raw" default values (meaning: not wrapped in Default or similar) as well as the special value dataclasses.MISSING as the default in validataclass_field(). This overcomplicates the typing without any real benefit, for a function that usually isn't used directly anyway.
    • You should use default objects instead, e.g. Default(...) instead of raw default values or NoDefault instead of dataclasses.MISSING.
  • Deprecate reusing TypeVars from the library by removing them from __all__. #134
    • Previously, TypeVars like T_Enum (used by the EnumValidator) could be imported and reused in user code. These TypeVars are for internal use and can be renamed or removed at any point. There also is no good reason to reuse them, it's better to just define your own TypeVars instead.
    • The TypeVars still exist and can still be imported, but since they're removed from __all__, linters should complain about importing them. This effectively deprecates usings them without breaking anything during runtime.

Removed

  • Drop support for Python 3.8. #128
  • Drop support for Python 3.9. #130
  • Breaking change: Remove support for using Default() without any arguments. #136
    • This was an undocumented feature that most likely wasn't used anyway.
    • Previously, using Default() was equivalent to Default(None). You should use Default(None) instead, which is also more explicit.

Dependencies

  • Increase minimum required version of typing-extensions to 4.14. #131
  • Add conditional dependency tomli for Python version 3.10 and below. #141
    • The mypy plugin requires a TOML library to parse pyproject.toml. Tomli is a simple library without dependencies.
    • Since Python 3.11, the standard library comes with the module tomllib (which in fact is based on tomli), so the library will only installed for older Python versions.

Testing / CI

  • Improve file structure for tests: Move unit tests to tests/unit/. #133
  • Add pytest-mypy-plugins to testing dependencies. #134
    • This library is a pytest plugin that can be used to test the output of mypy for a given piece of code. It's mostly used for testing the custom mypy plugin, but also for verifying the typing of the generic-based validator classes.
  • Update testing dependencies and pin them to minor versions. #143
  • Update GitHub actions. #131, #143

Miscellaneous

  • Various code modernizations after dropping support for Python 3.8 and 3.9. #128, #130
  • Various typing improvements and fixes. #138

0.11.0 - 2024-08-12

Full changelog

This release makes the library PEP 561 compatible by adding a py.typed file. It also fixes some mypy issues that were previously ignored.

While there is still some work necessary to make the library fully compatible with mypy (see #116), this release enables mypy to detect the type annotations in the library without the need for stub files.

Important note / breaking changes

This update was originally released as patch version 0.10.1, but was then yanked and later re-released as a new minor version instead.

The update does not introduce any breaking changes in the code. However, it may result in mypy errors in your project which have previously not been discovered by mypy, thus leading to failing CI pipelines. Keep this in mind when updating the library.

Some of the issues found by mypy currently need to be ignored using # type: ignore comments, until the library is fully compatible with mypy (#116). Examples:

  • Return type "X" of "validate" incompatible with return type "Y" in supertype "SomeBaseValidator" [override]: This can happen when you subclass a validator and change the return type of the validate method, which technically violates the Liskov substitution principle. However, in the case of validators, that's intentional.
  • Item "UnsetValueType" of "X | UnsetValueType" has no attribute "Y": This can happen despite of conditions like if some_field is not UnsetValue:, because mypy doesn't know that UnsetValue is a sentinel object, thus not being able to narrow down the type. A possible workaround that doesn't require # type: ignore would be to define a Type Guard and use that instead of the bare condition.

We will hopefully find better solutions for these problems in the future.

Added

  • Add py.typed file to make the package PEP 561 compatible. #125

Fixed

  • Explicitly re-export imports in __init__.py by defining __all__ to fix mypy issues. #125

0.10.1 - 2024-08-08 [YANKED]

This release was yanked from PyPI and re-released as 0.11.0. (See release notes above.)

Reason: Starting with this release, the library is PEP 561 compatible, which means that mypy recognized it as a typed package. This can uncover some typing issues that have previously been ignored by mypy, leading to failing CI pipelines in projects that use the library with the recommended version constraint of ~=0.10.0. To prevent this, we yanked the version from PyPI and re-released it as a new minor release instead of a patch release.

Added

  • Add py.typed file to make the package PEP 561 compatible. #125

Fixed

  • Explicitly re-export imports in __init__.py by defining __all__ to fix mypy issues. #125

0.10.0 - 2024-05-07

Full changelog

This release features custom pre-validation in dataclasses using the __pre_validate__() method and a change to the accepted format of datetimes in the DateTimeValidator to accept arbitrary decimal places after seconds.

This also is a "spring cleaning" release that contains a lot of miscellaneous refactorings and code cleanup, as well as some preparation for full mypy support (#116).

It also drops support for Python 3.7 and adds support for Python 3.12.

Added

  • Official support for Python 3.12. #112
  • Custom pre-validation in dataclasses using the __pre_validate__ class method. #115

Changed

  • DateTimeValidator: Accept datetimes with arbitrary precision (by @flauschzelle). #111, #113
    • This is not a breaking change, unless you specifically want to restrict datetime input strings to exactly 0, 3 or 6 decimal places after the seconds. It does not really matter for the result.
  • Move ValidationError base class to separate module validataclass.exceptions.base_exceptions. #117
    • This should not break any code as long as you import ValidationError from the validataclass.exceptions package instead of the validataclass.exceptions.common_exceptions module. If you do import it from the module, it should still work because the class is imported there as well, but you might get linter warnings.
  • DataclassValidator: Simplify check and error handling for when the specified dataclass is not a dataclass. #120

Removed

  • Breaking change: Drop support for Python 3.7. #118
  • Remove python-dateutil from install requirements. #122
    • This library was previously a dependency of validataclass. However, it was only needed in the unit tests, so it has been moved to the testing extra requirements.

Fixed

  • Fix style of type comparisons in some unit tests (by @flauschzelle). #110
  • Fix various typing issues reported by mypy, add missing type annotations and other related changes. #120, #121

Testing / CI

  • Add mypy to development environment and CI pipeline. #120

Miscellaneous

  • DateTimeValidator: Unify class docstring with Markdown documentation. #113
  • Miscellaneous code reformatting, more consistent docstrings, unit test refactoring. #119

New contributors

0.9.0 - 2023-05-24

Full changelog

This release adds official support for Python for Workgroups 3.11, as well as some minor changes.

Added

  • EmailValidator: Add parameter to_lowercase. #106

Changed

  • Allow defining __post_validate__() with specific context arguments without **kwargs. #105

Fixed

  • Fix Python 3.11 incompatibilities due to UnsetValue not being hashable. #102
  • Also fix missing __hash__ methods in the Default classes (for completeness). #102

Testing / CI

  • Update GitHub actions to fix deprecation warnings. #103
  • Update local test environment for tox 4. #104

0.8.1 - 2022-11-30

Full changelog

Fixed

  • AnyOfValidator and EnumValidator: Fixed wrong default value. Now the validators are really case-insensitive by default.

0.8.0 - 2022-11-30

Full changelog

This release adds two new validators and a handful of new parameters to existing validators.

It also introduces two breaking changes, which in practice shouldn't really affect anyone negatively, and one deprecation of an existing validator parameter. See the changes below.

Added

  • AllowEmptyString: New wrapper validator that accepts empty strings (by @TomasHalgas). #91
  • DiscardValidator: New validator that discards any input and always returns a predefined value. #94
  • EmailValidator and RegexValidator: Add parameter allow_empty to allow empty strings (by @TomasHalgas). #89
  • EmailValidator: Add parameter max_length. #97
  • DecimalValidator: Add parameter rounding to specify rounding mode (with a new default, see "Changed"). #99

Changed

  • Breaking change: AnyOfValidator and EnumValidator are now case-sensitive by default. #98
    • The parameter case_insensitive is replaced with a new parameter case_sensitive which defaults to False.
    • The old parameter is still supported for compatibility, but is now deprecated and will be removed in a future version.
    • If you have set case_insensitive=True before, you can simply remove this parameter now as this is the default now.
  • Breaking change: DecimalValidator (and all subclasses) now uses decimal.ROUND_HALF_UP as default rounding mode. #99
    • Until now, the rounding mode of the current decimal context was used, which defaults to decimal.ROUND_HALF_EVEN.
    • Use the rounding parameter to change this. To restore the old behavior and use the decimal context, set rounding=None.

Deprecated

  • AnyOfValidator and EnumValidator: The parameter case_insensitive is now deprecated and will be removed in a future version. (See "Changed" above.) #98

Testing

  • Fix version incompatibility in test suite. #95
  • AnyOfValidator: Add unit tests with an empty list for allowed values. #96

New contributors

0.7.2 - 2022-09-26

Full changelog

This patch fix a bug with the type hinting for @validataclass and DataclassValidator introduced in 0.7.1.

Fixed

  • Fixed typehints of @validataclass decorator. Auto-deduction in DataclassValidator should work now. #85

0.7.1 - 2022-09-26

Full changelog

This small patch release improves type hinting for the @validataclass decorator and the DataclassValidation.

Changed

  • DataclassValidator: The exact type of the validator (e.g. DataclassValidator[MyDataclass]) and thus the return type of validate() is now auto-deduced from the constructor arguments without an explicit type annotation. #84
  • The @validataclass decorator has (hopefully correct) type annotations now. #84

0.7.0 - 2022-09-22

Full changelog

This release mainly introduces context-sensitive (post-)validation. There are some more additions planned for this feature (e.g. dependencies between dataclass fields), but for now we have a solid base.

It also features a handful of smaller additions and changes, see below.

There is a potential breaking change (which probably won't affect anybody), and a sort of deprecation that will affect most custom validators in the future, so make sure to upgrade your validators as explained below.

Added

  • Basic support for context-sensitive validation. #77
    • All built-in validators now support arbitrary keyword arguments (so called context arguments) in the validate() method. These can be used to change the behavior of a validator at validation time based on some kind of application context. Most validators don't do anything with them except passing them down to child validators (e.g. to the item validators in a ListValidator, etc.), but you can implement custom validators that use them.
    • To keep compatibility with custom validators that do not accept context arguments yet, a provisional helper method validate_with_context() was added to the base Validator class. This method simply calls the validate() method, but checks whether it supports context arguments. If yes, context arguments are passed to validate(), else validate() is called without any extra arguments. This method will become obsolete and eventually removed in the future, and should only be used in cases where it is unsure whether a validator supports context arguments.
  • Context-sensitive post-validation in dataclasses. #77
    • The DataclassValidator will now call the method __post_validate__() on your dataclass instances if you have defined this method. Additionally, if the method accepts arbitrary keyword arguments (i.e. **kwargs, although the name of this parameter doesn't matter), all context arguments will be passed to it.
    • You can use this to implement context-sensitive post-validation. For example, if you implement a PATCH endpoint in a REST API, you could have fields that are sometimes optional and sometimes required, depending on a property of the object the user wants to update. You can now fetch the object before calling validate(), then pass the object (or just the property) as a context argument to validate(), and then access it in __post_validate__() to implement a context-sensitive field requirement check.
    • The __post_init__() method of regular dataclasses can still be used for post-validation as before. It cannot be used context-sensitively, though, because we cannot pass arbitrary keyword arguments to it.
  • DateTimeValidator: Add parameter discard_milliseconds to discard the milli- and microseconds of datetimes. #79
  • AnyOfValidator and EnumValidator: Add parameter case_insensitive for case-insensitive string matching. #81
  • New helper function unset_to_none() (returns None if value is UnsetValue). #76

Changed

  • All built-in validators now support context arguments in the validate() method. See above. #77
  • The validate() method of the DataclassValidator was restructured a bit for easier extendability. (This may be subject of additional changes in the future, though.) #77
  • The @validataclass decorator is now marked as a "data class transform" using the @dataclass_transform decorator as specified in PEP 681. #78
    • Since this decorator was only introduced in Python 3.11, we use the typing-extensions library which backports new typing features like this.
  • ListValidator and EnumValidator are now defined as generic classes for better type hinting. #80
  • AnyOfValidator and EnumValidator now accept allowed_values and allowed_types as any iterable. #80
  • AnyOfValidator and EnumValidator: The ValueNotAllowedError now lists all allowed values (unless they are more than 20). #81

Deprecated

  • Validator classes that do not accept context arguments are now deprecated. #77
    • When defining a Validator subclass, the __init_subclass__() method will check whether your validate() method accepts arbitrary keyword arguments. If not, a DeprecationWarning will be issued.
    • Existing custom validators will keep working for now, but this compatibility will be removed in version 1.0.
    • To update your custom validators, simply add **kwargs to the parameter list of validate(). If your validator class is based on an existing validator, make sure to pass the context arguments down to the validate() of your base class as well, i.e. super().validate(input_data, **kwargs).

Removed

  • Breaking change: The post_validate() method of the DataclassValidator was removed. #77
    • (This should not to be confused with the new __post_validate__(), however, which is a method of dataclasses, not of the validator itself.)
    • This method was removed because a) post-validation using either __post_init__() or the new __post_validate__() method in the dataclass should be preferred, b) the validator was restructured in a way that makes this method redundant, and c) it was probably never used anyway.
    • If you do need post-validation as part of a subclassed DataclassValidator, you can extend either validate() or the new _post_validate() private method (but make sure to extend, not override it, since it also handles the call of the dataclass's __post_validate__() method).

0.6.2 - 2022-07-11

Full changelog

This release fixes a bug with multiple inheritance in validataclasses.

Fixed

  • Fix overriding of existing field properties in validataclasses with multiple inheritance. #71

0.6.1 - 2022-06-16

Full changelog

This release fixes a critical bug introduced in 0.6.0.

Added

  • Default objects now support equality comparison (implemented __eq__). #69

Fixed

  • Fix Default objects with mutable values (e.g. lists). #69

0.6.0 - 2022-06-15

Full changelog

This release features a reimplementation of field defaults in validataclasses (for details, see #63 and #65), a bit of code restructuring and a new parameter for the RegexValidator.

There is a potential breaking change and multiple deprecations.

Added

  • RegexValidator: Add parameter output_template to generate output strings from a template (by @lahdjirayhan). #61

Changed

  • Reimplementation of field defaults in validataclasses to be more consistent with regular dataclasses. #65
    • Optional validataclass fields now have proper dataclass default values (additionally to the validataclass-specific Default objects).
    • This means that validataclasses can now be instantiated in the same way as regular dataclasses, without the need of the ValidataclassMixin.create_with_defaults() class method.
    • In Python 3.10 and higher, the new dataclass flag kw_only=True is used to allow for required and optional fields to be defined in any order. In older Python versions, a workaround is used instead (every required field will have a default_factory that raises an exception if the field is omitted).
    • Breaking change: Due to the kw_only=True flag, instantiating validataclass objects using positional arguments (e.g. MyDataclass(42, 'foo') is not supported anymore, starting with Python 3.10. It's recommended to use keyword arguments instead (e.g. MyDataclass(foo=42, bar='foo')).
  • Moved all dataclass related helpers from validataclass.helpers to separate modules in validataclass.dataclasses. #66
    • Please adjust your imports. Importing from the old location will stop working in a future version.
    • Affected are: The validataclass decorator, validataclass_field(), ValidataclassMixin, Default, DefaultFactory, DefaultUnset and NoDefault.
    • To find all imports that need adjustment, search your code for validataclass.helpers. The old imports will emit deprecation warnings now, so it might also help to enable deprecation warnings.
  • The CI pipeline will now fail if the code coverage sinks below 100%. #65

Deprecated

  • ValidataclassMixin: The create_with_defaults() class method is now deprecated as it is no longer needed. #65
    • To create an instance of a validataclass, you can now simply use the regular dataclass constructor, e.g. MyDataclass(foo=42, ...) instead of MyDataclass.create_with_defaults(foo=42, ...).
  • Importing dataclass related helpers from validataclass.helpers is now deprecated since they have moved (see above). #66

0.5.0 - 2022-05-12

Full changelog

This release introduces some new validators, new parameters for existing validators and some other smaller changes.

There are two potentially breaking changes (#51 and #59), although it's very unlikely that any existing code is negatively affected by it.

Added

  • AnythingValidator: New validator that accepts any input without validation. #56
  • RejectValidator: New validator that rejects any input. #55
  • NoneToUnsetValue: New validator as a shortcut for Noneable(..., default=UnsetValue). #57
  • ListValidator: Add parameter discard_invalid to ignore invalid list elements (by @lahdjirayhan). #43
  • UrlValidator: Add parameters allow_empty and max_length (by @lahdjirayhan). #49
  • RegexValidator: Add parameter custom_error_class to set a custom exception class. #54

Changed

  • IntegerValidator: Set defaults for min_value and max_value to restrict input to 32-bit integers. #51
  • Noneable: Raise exception if wrapped validator is not a valid Validator object. #52
  • DecimalValidator: Allow min_value and max_value parameters to be specified as integers. #53
  • DataclassValidator: Don't wrap uncaught exceptions in InternalValidationError anymore. #59

Removed

  • Removed InternalValidationError exception. #59

Fixed

  • GitHub CI: Fix running unit test workflows in pull requests from forked repositories. #45, #47, #48

New contributors

0.4.0 - 2022-02-01

Full changelog

Added

  • Official support for Python 3.10. #30
  • IntegerValidator: Add optional boolean parameter allow_strings to accept integer strings as input (e.g. "123"). #31
  • FloatValidator: Add optional boolean parameter allow_integers. #32
  • FloatToDecimalValidator: Add optional boolean parameters allow_integers and allow_strings. Also, minimum and maximum values can now be specified as floats, integers, Decimal or decimal strings. #32
  • NumericValidator: New validator as shortcut for FloatToDecimalValidator with allow_integers and allow_strings. #33
  • StringValidator: Added some unit tests for strings with unicode characters (including emoji). #34

Changed

  • FloatToDecimalValidator: Reimplemented validator, based on DecimalValidator instead of FloatValidator. #33
    • NumberRangeError exceptions raised by this validator now consistently use decimal strings for min/max values.

Fixed

  • Minor fixes for Optional type hints. #30
  • Add missing export for T_Dataclass in package validataclass.validators. #30

0.3.2 - 2021-11-11

Full changelog

Changed

  • ValidataclassMixin: The to_dict() method now removes UnsetValues from the dictionary, unless the optional parameter keep_unset_values=True is set. #28

0.3.1 - 2021-11-11

Full changelog

Changed

  • @validataclass decorator detects fields with validator but without type annotations and will raise errors about that now. #27

Fixed

  • @validataclass allows empty dataclasses now (raised an AttributeError before). #27

0.3.0 - 2021-11-10

Full changelog

Added

  • Support for class inheritance of validataclasses, e.g. extend an existing validataclass by adding new fields setting different default values for existing fields. #11
  • Type aliases OptionalUnset[T] and OptionalUnsetNone[T]. #12
  • Mixin class ValidataclassMixin with methods to_dict() and create_with_defaults(). #13

Changed

  • Tuples for specifying field validators and defaults in a validataclass can now be in any order, so (default, validator) instead of (validator, default) is allowed now. (Side effect of #11)

Fixed

  • Fix link to docs in README.md to make link work on PyPI. #8

0.2.0 - 2021-10-25

Full changelog

Added

Changed

  • DefaultUnset is now a sentinel object instead of a class. #4

Fixed

  • Value in Default class is now deepcopied on retrieval. #3
  • Typesafe comparisons of integers and booleans in AnyOfValidator. #5

0.1.0 - 2021-10-07

Full changelog

General

  • Initial release.
  • Full rewrite of previous library wtfjson from scratch.
  • Rename to validataclass.
  • Automated unit testing with 100% code coverage.
  • Automated publishing on PyPI.

Added

  • Added first validators:
    • Basic type validators: BooleanValidator, IntegerValidator, FloatValidator, StringValidator
    • Decimal validators: DecimalValidator, FloatToDecimalValidator
    • Choice validators: AnyOfValidator, EnumValidator
    • Date and time validators: DateValidator, TimeValidator, DateTimeValidator
    • Extended string validators: RegexValidator, EmailValidator, UrlValidator
    • Meta validators: Noneable
    • Composite type validators: ListValidator, DictValidator
  • Implemented dataclass support:
    • Validator: DataclassValidator
    • Helper functions: validataclass_field(), @validataclass
    • Default classes: Default, DefaultFactory, DefaultUnset

Known issues

  • No documentation yet (will follow in 0.2.0).