Skip to content

runtime checking comparison doc #1050

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

runtime checking comparison doc #1050

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 13 additions & 1 deletion doc/comparisons.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,19 @@ In practice, most programmers simply skip validation or implement it only partia

## Runtime checking

Python 3 type annotations allow users to specify types for attributes and function returns, but these types are not normally checked at runtime, and so they do not have the same role of validating user input or programmer error as the type declarations in Params, Traits, Traitlets, pydantic, and attr. They also are limited to the type, so they cannot enforce constraints on range ('state' must be in the list ['Alabama', 'Alaska',...]). Thus even if type hinting is used, programmers still need to write code to actually validate the inputs to functions and methods, which is the role of packages like Param and Traitlets. Note that Pydantic focuses on [generating valid outputs at runtime](https://github.com/samuelcolvin/pydantic/issues/578) rather than detecting invalid inputs, so it may or may not be suitable for the same types of applications as the other libraries discussed here.
Python type annotations allow users to specify types for attributes and function returns.
These types are optionally checked at runtime in contrast to Param.

However, one point of difference is that Param has (built-in) 'value level' checking
such as checking membership of a state in a list ['Alabama', 'Alaska', ...].
With Python type annotations, there would be several ways:
- statically-defined type-level logical specification: `Literal['Alabama'] | Literal['Alaska'] | ...`
- run-time checking by adding a predicate to `Annotated[str, lambda s: s in states]`
used by [Beartype](https://beartype.readthedocs.io/en/latest/)
- creating a `State` type and defining the predicate `__instancecheck__`
as used in [phantom-types](https://phantom-types.readthedocs.io/en/main/pages/implementation.html).

Even with type-level definitions, Pydantic may [coerce types](https://docs.pydantic.dev/latest/concepts/conversion_table/) which caters more to data validation use cases.


## Generality and ease of integration with your project
Expand Down