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
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.
- 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.mdfor 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_fieldscan be set both in the@validataclassdecorator and theDataclassValidator. - If this option is
True, theDataclassValidatorwill reject unknown fields with afield_not_allowederror. This is the same validation error used by theRejectValidator. - When the option is set both in the
@validataclassdecorator and in theDataclassValidator, the option of theDataclassValidatortakes 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.
- The new option
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
Validatoris now a generic class with one type parameter. This type parameter specifies the type of the output of this validator: Given a validator of typeValidator[T], the return type ofvalidator.validate()must beT. This does not relate to the type of input data. - For example, the
DecimalValidatoris of typeValidator[Decimal]because it always returns aDecimalobject. - Validator classes can have their own type parameters as well. For example, the
ListValidatorhas a type parameter to indicate the type of items in the returned list:ListValidator[T]inherits fromValidator[list[T]], it requires an item validator of typeValidator[T]and always returns alist[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 asListValidator[str]. However, there are some edge cases where type inference doesn't always work (e.g. forDictValidator). 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: ignorefor 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
DecimalValidatoras a subclassedStringValidatorwill 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_lengthfromStringValidator) might not be accessible directly anymore. In general, you should not rely on the existence or names of attributes in validator classes.
- The validator base class
- Generic-based typing for default objects. #136
- Default classes (e.g.
Default,DefaultFactory) all inherit from a new generic base classBaseDefault[T]now, whereTspecifies the type of the actual default value. (Previously,Defaultwas the base class, which was problematic for several reasons.) - The classes
Default[T]andDefaultFactory[T]are generic as well, specifying the type of their output value.
- Default classes (e.g.
DefaultUnsetis now simply an alias forDefault(UnsetValue)rather than a special subclass. #136- As a side effect, its string representation (
repr(DefaultUnset)) has changed toDefault(UnsetValue). - Also,
DefaultUnsetis not unique anymore. Use==rather thanisto check if something isDefaultUnset.
- As a side effect, its string representation (
- The
defaultparameter ofvalidataclass_field()is keyword-only now, to be consistent withdataclasses.field(). #140 Validator: The helper method_ensure_type()now allowsNoneifNoneTypeis in the list of expected types. #134- Several error messages have been changed for consistency. This usually shouldn't have any effect on code.
The following things have been deprecated and might be removed in a future version (possibly the next minor release).
- Deprecate calling
DefaultUnset()andNoDefault(). #136- You should use them without parentheses instead:
DefaultUnsetandNoDefault.
- You should use them without parentheses instead:
validataclass_field(): Deprecate using thedefaultargument with "raw" values anddataclasses.MISSING. #140- Currently, you can use "raw" default values (meaning: not wrapped in
Defaultor similar) as well as the special valuedataclasses.MISSINGas the default invalidataclass_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 orNoDefaultinstead ofdataclasses.MISSING.
- Currently, you can use "raw" default values (meaning: not wrapped in
- Deprecate reusing TypeVars from the library by removing them from
__all__. #134- Previously, TypeVars like
T_Enum(used by theEnumValidator) 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.
- Previously, TypeVars like
- 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 toDefault(None). You should useDefault(None)instead, which is also more explicit.
- Increase minimum required version of
typing-extensionsto 4.14. #131 - Add conditional dependency
tomlifor 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 ontomli), so the library will only installed for older Python versions.
- The mypy plugin requires a TOML library to parse
- 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
- 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
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.
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 thevalidatemethod, 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 likeif some_field is not UnsetValue:, because mypy doesn't know thatUnsetValueis a sentinel object, thus not being able to narrow down the type. A possible workaround that doesn't require# type: ignorewould 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.
- Add
py.typedfile to make the package PEP 561 compatible. #125
- Explicitly re-export imports in
__init__.pyby 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.
- Add
py.typedfile to make the package PEP 561 compatible. #125
- Explicitly re-export imports in
__init__.pyby defining__all__to fix mypy issues. #125
0.10.0 - 2024-05-07
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.
- Official support for Python 3.12. #112
- Custom pre-validation in dataclasses using the
__pre_validate__class method. #115
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
ValidationErrorbase class to separate modulevalidataclass.exceptions.base_exceptions. #117- This should not break any code as long as you import
ValidationErrorfrom thevalidataclass.exceptionspackage instead of thevalidataclass.exceptions.common_exceptionsmodule. 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.
- This should not break any code as long as you import
DataclassValidator: Simplify check and error handling for when the specified dataclass is not a dataclass. #120
- Breaking change: Drop support for Python 3.7. #118
- Remove
python-dateutilfrom 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
testingextra requirements.
- This library was previously a dependency of validataclass. However, it was only needed in the unit tests, so it has
been moved to the
- 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
DateTimeValidator: Unify class docstring with Markdown documentation. #113- Miscellaneous code reformatting, more consistent docstrings, unit test refactoring. #119
- @flauschzelle made her first contributions in #110 and #111.
0.9.0 - 2023-05-24
This release adds official support for Python for Workgroups 3.11, as well as some minor changes.
EmailValidator: Add parameterto_lowercase. #106
- Allow defining
__post_validate__()with specific context arguments without**kwargs. #105
- Fix Python 3.11 incompatibilities due to
UnsetValuenot being hashable. #102 - Also fix missing
__hash__methods in theDefaultclasses (for completeness). #102
- Update GitHub actions to fix deprecation warnings. #103
- Update local test environment for tox 4. #104
0.8.1 - 2022-11-30
AnyOfValidatorandEnumValidator: Fixed wrong default value. Now the validators are really case-insensitive by default.
0.8.0 - 2022-11-30
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.
AllowEmptyString: New wrapper validator that accepts empty strings (by @TomasHalgas). #91DiscardValidator: New validator that discards any input and always returns a predefined value. #94EmailValidatorandRegexValidator: Add parameterallow_emptyto allow empty strings (by @TomasHalgas). #89EmailValidator: Add parametermax_length. #97DecimalValidator: Add parameterroundingto specify rounding mode (with a new default, see "Changed"). #99
- Breaking change:
AnyOfValidatorandEnumValidatorare now case-sensitive by default. #98- The parameter
case_insensitiveis replaced with a new parametercase_sensitivewhich 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=Truebefore, you can simply remove this parameter now as this is the default now.
- The parameter
- Breaking change:
DecimalValidator(and all subclasses) now usesdecimal.ROUND_HALF_UPas 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
roundingparameter to change this. To restore the old behavior and use the decimal context, setrounding=None.
- Until now, the rounding mode of the current decimal context was used, which defaults to
AnyOfValidatorandEnumValidator: The parametercase_insensitiveis now deprecated and will be removed in a future version. (See "Changed" above.) #98
- Fix version incompatibility in test suite. #95
AnyOfValidator: Add unit tests with an empty list for allowed values. #96
- @TomasHalgas made their first contributions in #89 and #91.
0.7.2 - 2022-09-26
This patch fix a bug with the type hinting for @validataclass and DataclassValidator introduced in 0.7.1.
- Fixed typehints of
@validataclassdecorator. Auto-deduction inDataclassValidatorshould work now. #85
0.7.1 - 2022-09-26
This small patch release improves type hinting for the @validataclass decorator and the DataclassValidation.
DataclassValidator: The exact type of the validator (e.g.DataclassValidator[MyDataclass]) and thus the return type ofvalidate()is now auto-deduced from the constructor arguments without an explicit type annotation. #84- The
@validataclassdecorator has (hopefully correct) type annotations now. #84
0.7.0 - 2022-09-22
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.
- 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 aListValidator, 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 baseValidatorclass. This method simply calls thevalidate()method, but checks whether it supports context arguments. If yes, context arguments are passed tovalidate(), elsevalidate()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.
- All built-in validators now support arbitrary keyword arguments (so called context arguments) in the
- Context-sensitive post-validation in dataclasses. #77
- The
DataclassValidatorwill 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
PATCHendpoint 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 callingvalidate(), then pass the object (or just the property) as a context argument tovalidate(), 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.
- The
DateTimeValidator: Add parameterdiscard_millisecondsto discard the milli- and microseconds of datetimes. #79AnyOfValidatorandEnumValidator: Add parametercase_insensitivefor case-insensitive string matching. #81- New helper function
unset_to_none()(returnsNoneif value isUnsetValue). #76
- All built-in validators now support context arguments in the
validate()method. See above. #77 - The
validate()method of theDataclassValidatorwas restructured a bit for easier extendability. (This may be subject of additional changes in the future, though.) #77 - The
@validataclassdecorator is now marked as a "data class transform" using the@dataclass_transformdecorator 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.
ListValidatorandEnumValidatorare now defined as generic classes for better type hinting. #80AnyOfValidatorandEnumValidatornow acceptallowed_valuesandallowed_typesas any iterable. #80AnyOfValidatorandEnumValidator: TheValueNotAllowedErrornow lists all allowed values (unless they are more than 20). #81
- Validator classes that do not accept context arguments are now deprecated. #77
- When defining a
Validatorsubclass, the__init_subclass__()method will check whether yourvalidate()method accepts arbitrary keyword arguments. If not, aDeprecationWarningwill 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
**kwargsto the parameter list ofvalidate(). If your validator class is based on an existing validator, make sure to pass the context arguments down to thevalidate()of your base class as well, i.e.super().validate(input_data, **kwargs).
- When defining a
- Breaking change: The
post_validate()method of theDataclassValidatorwas 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 eithervalidate()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).
- (This should not to be confused with the new
0.6.2 - 2022-07-11
This release fixes a bug with multiple inheritance in validataclasses.
- Fix overriding of existing field properties in validataclasses with multiple inheritance. #71
0.6.1 - 2022-06-16
This release fixes a critical bug introduced in 0.6.0.
Defaultobjects now support equality comparison (implemented__eq__). #69
- Fix
Defaultobjects with mutable values (e.g. lists). #69
0.6.0 - 2022-06-15
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.
RegexValidator: Add parameteroutput_templateto generate output strings from a template (by @lahdjirayhan). #61
- 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
Defaultobjects). - 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=Trueis 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 adefault_factorythat raises an exception if the field is omitted). - Breaking change: Due to the
kw_only=Trueflag, 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')).
- Optional validataclass fields now have proper dataclass default values (additionally to the validataclass-specific
- Moved all dataclass related helpers from
validataclass.helpersto separate modules invalidataclass.dataclasses. #66- Please adjust your imports. Importing from the old location will stop working in a future version.
- Affected are: The
validataclassdecorator,validataclass_field(),ValidataclassMixin,Default,DefaultFactory,DefaultUnsetandNoDefault. - 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
ValidataclassMixin: Thecreate_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 ofMyDataclass.create_with_defaults(foo=42, ...).
- To create an instance of a validataclass, you can now simply use the regular dataclass constructor, e.g.
- Importing dataclass related helpers from
validataclass.helpersis now deprecated since they have moved (see above). #66
0.5.0 - 2022-05-12
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.
AnythingValidator: New validator that accepts any input without validation. #56RejectValidator: New validator that rejects any input. #55NoneToUnsetValue: New validator as a shortcut forNoneable(..., default=UnsetValue). #57ListValidator: Add parameterdiscard_invalidto ignore invalid list elements (by @lahdjirayhan). #43UrlValidator: Add parametersallow_emptyandmax_length(by @lahdjirayhan). #49RegexValidator: Add parametercustom_error_classto set a custom exception class. #54
IntegerValidator: Set defaults formin_valueandmax_valueto restrict input to 32-bit integers. #51Noneable: Raise exception if wrapped validator is not a validValidatorobject. #52DecimalValidator: Allowmin_valueandmax_valueparameters to be specified as integers. #53DataclassValidator: Don't wrap uncaught exceptions inInternalValidationErroranymore. #59
- Removed
InternalValidationErrorexception. #59
- @lahdjirayhan made their first contributions in #43 and #49.
0.4.0 - 2022-02-01
- Official support for Python 3.10. #30
IntegerValidator: Add optional boolean parameterallow_stringsto accept integer strings as input (e.g."123"). #31FloatValidator: Add optional boolean parameterallow_integers. #32FloatToDecimalValidator: Add optional boolean parametersallow_integersandallow_strings. Also, minimum and maximum values can now be specified as floats, integers,Decimalor decimal strings. #32NumericValidator: New validator as shortcut forFloatToDecimalValidatorwithallow_integersandallow_strings. #33StringValidator: Added some unit tests for strings with unicode characters (including emoji). #34
FloatToDecimalValidator: Reimplemented validator, based onDecimalValidatorinstead ofFloatValidator. #33NumberRangeErrorexceptions raised by this validator now consistently use decimal strings for min/max values.
- Minor fixes for
Optionaltype hints. #30 - Add missing export for
T_Dataclassin packagevalidataclass.validators. #30
0.3.2 - 2021-11-11
ValidataclassMixin: Theto_dict()method now removes UnsetValues from the dictionary, unless the optional parameterkeep_unset_values=Trueis set. #28
0.3.1 - 2021-11-11
@validataclassdecorator detects fields with validator but without type annotations and will raise errors about that now. #27
@validataclassallows empty dataclasses now (raised an AttributeError before). #27
0.3.0 - 2021-11-10
- 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]andOptionalUnsetNone[T]. #12 - Mixin class
ValidataclassMixinwith methodsto_dict()andcreate_with_defaults(). #13
- 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)
- Fix link to docs in README.md to make link work on PyPI. #8
0.2.0 - 2021-10-25
- Initial version of documentation. #6
- Added changelog file. #7
DefaultUnsetis now a sentinel object instead of a class. #4
- Value in
Defaultclass is now deepcopied on retrieval. #3 - Typesafe comparisons of integers and booleans in
AnyOfValidator. #5
0.1.0 - 2021-10-07
- 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 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
- Basic type validators:
- Implemented dataclass support:
- Validator:
DataclassValidator - Helper functions:
validataclass_field(),@validataclass - Default classes:
Default,DefaultFactory,DefaultUnset
- Validator:
- No documentation yet (will follow in 0.2.0).