vtjson 2.1.7__tar.gz → 2.1.8__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {vtjson-2.1.7/src/vtjson.egg-info → vtjson-2.1.8}/PKG-INFO +20 -20
- {vtjson-2.1.7 → vtjson-2.1.8}/README.md +19 -19
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson/vtjson.py +1 -1
- {vtjson-2.1.7 → vtjson-2.1.8/src/vtjson.egg-info}/PKG-INFO +20 -20
- {vtjson-2.1.7 → vtjson-2.1.8}/AUTHORS +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/LICENSE +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/pyproject.toml +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/setup.cfg +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson/__init__.py +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson/py.typed +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson.egg-info/SOURCES.txt +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson.egg-info/dependency_links.txt +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson.egg-info/requires.txt +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/src/vtjson.egg-info/top_level.txt +0 -0
- {vtjson-2.1.7 → vtjson-2.1.8}/tests/test_vtjson.py +0 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.1
|
|
2
2
|
Name: vtjson
|
|
3
|
-
Version: 2.1.
|
|
3
|
+
Version: 2.1.8
|
|
4
4
|
Summary: A lightweight package for validating JSON like Python objects
|
|
5
5
|
Author-email: Michel Van den Bergh <michel.vandenbergh@uhasselt.be>
|
|
6
6
|
Project-URL: Homepage, https://github.com/vdbergh/vtjson
|
|
@@ -24,14 +24,14 @@ A lightweight package for validating JSON like Python objects.
|
|
|
24
24
|
|
|
25
25
|
## Schemas
|
|
26
26
|
|
|
27
|
-
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an [
|
|
27
|
+
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an example one may consult the [schema of the run object](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example1.md) in the mongodb database underlying the Fishtest web application <https://tests.stockfishchess.org/tests>.
|
|
28
28
|
|
|
29
29
|
The following conventions are used:
|
|
30
30
|
|
|
31
31
|
- As in typescript, a (string) key ending in `?` represents an optional key. The corresponding schema (the item the key points to) will only be used for validation when the key is present in the object that should be validated. A key can also be made optional by wrapping it as `optional_key(key)`.
|
|
32
32
|
- If in a list/tuple the last entry is `...` (ellipsis) it means that the next to last entry will be repeated zero or more times. In this way generic types can be created. For example the schema `[str, ...]` represents a list of strings.
|
|
33
33
|
|
|
34
|
-
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type
|
|
34
|
+
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type annotation. Here is the above example rewritten in a way that is [compatible with type annotations](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example2.md). E.g. if one wants to ensure that a run object obtained via an api has the correct type one can do
|
|
35
35
|
|
|
36
36
|
```python
|
|
37
37
|
from typing import assert_type
|
|
@@ -160,7 +160,7 @@ A schema can be, in order of precedence:
|
|
|
160
160
|
```
|
|
161
161
|
|
|
162
162
|
where the optional argument `_deferred_compiles` is an opaque data structure used for handling recursive schemas. If appropriate, the function `_compile` internally invokes the method `schema.__compile__` and this should produce an instance of the class `compiled_schema`. The method `__compile__` may invoke the function `_compile` again. If this happens then the optional argument `_deferred_compiles` should be passed unmodified. Please consult the source code of `vtjson` for more details.
|
|
163
|
-
- A Python type
|
|
163
|
+
- A Python type annotation such as `list[str]`. This is discussed further below.
|
|
164
164
|
- A Python type. In that case validation is done by checking membership. By convention the schema `float` matches both ints and floats. Similarly the schema `complex` matches ints and floats besides of course complex numbers.
|
|
165
165
|
- A callable. Validation is done by applying the callable to the object. If applying the callable throws an exception then the corresponding message will be part of the non-validation message.
|
|
166
166
|
- An instance of `Sequence` that is not an instance of `str` (e.g a `list` or a `tuple`). Validation is done by first checking membership of the schema type, and then performing validation for each of the entries of the object being validated against the corresponding entries of the schema.
|
|
@@ -168,7 +168,7 @@ A schema can be, in order of precedence:
|
|
|
168
168
|
- A `set`. A set validates an object if the object is a set and the elements of the object are validated by an element of the schema.
|
|
169
169
|
- An arbitrary Python object. Validation is done by checking equality of the schema and the object, except when the schema is `float`, in which case `math.isclose` is used. Below we call such an object a `const schema`.
|
|
170
170
|
|
|
171
|
-
## Validating Mapping
|
|
171
|
+
## Validating against Mapping schemas
|
|
172
172
|
|
|
173
173
|
For a Mapping schema containing only `const keys` (i.e. keys corresponding to a `const schema`) the interpretation is obvious (see the introductory example above). Below we discuss the validation of an object against a Mapping schema in the general case.
|
|
174
174
|
|
|
@@ -182,11 +182,11 @@ For a Mapping schema containing only `const keys` (i.e. keys corresponding to a
|
|
|
182
182
|
|
|
183
183
|
A consequence of this algorithm is that non-const keys are automatically optional. So applying the wrapper `optional_key` to them is meaningless and has no effect.
|
|
184
184
|
|
|
185
|
-
## Type
|
|
185
|
+
## Type annotations integration
|
|
186
186
|
|
|
187
|
-
### Type
|
|
187
|
+
### Type annotations as schemas
|
|
188
188
|
|
|
189
|
-
`vtjson` recognizes the following type
|
|
189
|
+
`vtjson` recognizes the following type annotations as schemas.
|
|
190
190
|
|
|
191
191
|
```python
|
|
192
192
|
Annotated, Mapping[...,...] and subtypes, Container[...] and subtypes,
|
|
@@ -194,14 +194,14 @@ tuple[...], Tuple[...], Protocol, NamedTuple, Literal, NewType, TypedDict,
|
|
|
194
194
|
Union (or the equivalent operator |), Any.
|
|
195
195
|
```
|
|
196
196
|
|
|
197
|
-
For example `
|
|
197
|
+
For example `dict[str, str]` is translated internally into the schema `{str: str}`. See below for more information.
|
|
198
198
|
|
|
199
199
|
### Annotated
|
|
200
200
|
|
|
201
|
-
- More general vtjson schemas can work along Python type
|
|
201
|
+
- More general vtjson schemas can work along Python type annotations by using the `typing.Annotated` contruct. The most naive way to do this is via
|
|
202
202
|
|
|
203
203
|
```python
|
|
204
|
-
Annotated[
|
|
204
|
+
Annotated[type_annotation, vtjson_schema, skip_first]
|
|
205
205
|
```
|
|
206
206
|
|
|
207
207
|
For example
|
|
@@ -210,8 +210,8 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
210
210
|
Annotated[list[object], [int, str, float], skip_first]
|
|
211
211
|
```
|
|
212
212
|
|
|
213
|
-
A type checker such as `mypy` will only see the type
|
|
214
|
-
- In some use cases a vtjon_schema will meaningfully refine a Python type or type
|
|
213
|
+
A type checker such as `mypy` will only see the type annotation (`list[object]` in the example), whereas vtjson will only see the vtjson schema (`[int, str, float]` in the example). `skip_first` is a built-in short hand for `Apply(skip_first=True)` (see below) which directs vtjson to ignore the first argument of an `Annotated` schema.
|
|
214
|
+
- In some use cases a vtjon_schema will meaningfully refine a Python type or type annotation. In that case one should not use `skip_first`. For example:
|
|
215
215
|
|
|
216
216
|
```python
|
|
217
217
|
Annotated[datetime, fields({"tzinfo": timezone.utc})]
|
|
@@ -226,18 +226,18 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
226
226
|
```
|
|
227
227
|
|
|
228
228
|
matches even integers.
|
|
229
|
-
- If one wants to pre-compile a schema and still use it as a type
|
|
229
|
+
- If one wants to pre-compile a schema and still use it as a type annotation (assuming it is valid as such) then one can do:
|
|
230
230
|
|
|
231
231
|
```python
|
|
232
232
|
schema = <schema definition>
|
|
233
233
|
Schema = Annotated[schema, compile(schema), skip_first]
|
|
234
234
|
```
|
|
235
235
|
|
|
236
|
-
### Supported type
|
|
236
|
+
### Supported type annotations
|
|
237
237
|
|
|
238
|
-
Note that Python imposes strong restrictions on what constitutes a valid type
|
|
238
|
+
Note that Python imposes strong restrictions on what constitutes a valid type annotation but `vtjson` is much more lax about this. Enforcing the restrictions is left to the type checkers or the Python interpreter.
|
|
239
239
|
|
|
240
|
-
- `TypedDict`. A TypedDict type
|
|
240
|
+
- `TypedDict`. A TypedDict type annotation is translated into a `dict` schema. E.g.
|
|
241
241
|
|
|
242
242
|
```python
|
|
243
243
|
class Movie(TypedDict):
|
|
@@ -273,9 +273,9 @@ Note that Python imposes strong restrictions on what constitutes a valid type hi
|
|
|
273
273
|
|
|
274
274
|
- `tuple[...]` and `Tuple[...]` are translated into the equivalent `tuple` schemas.
|
|
275
275
|
|
|
276
|
-
- `Mapping[
|
|
276
|
+
- `Mapping[S, T]` and subtypes validate those objects that are members of the origin type (a subclass of `Mapping`) and whose (key, value) pairs match `(S, T)`.
|
|
277
277
|
|
|
278
|
-
- `Container[
|
|
278
|
+
- `Container[T]` and subtypes validate those objects that are members of the origin type (a subclass of `Container`) and whose elements match `T`.
|
|
279
279
|
|
|
280
280
|
- `Union` and the `|` operator are translated into `union`.
|
|
281
281
|
|
|
@@ -309,7 +309,7 @@ Vtjson includes the command
|
|
|
309
309
|
safe_cast(schema, object)
|
|
310
310
|
```
|
|
311
311
|
|
|
312
|
-
(where `schema` should be a valid type
|
|
312
|
+
(where `schema` should be a valid type annotation) that functions exactly like `cast` except that it also verifies at run time that the given object matches the given schema.
|
|
313
313
|
|
|
314
314
|
## Creating types
|
|
315
315
|
|
|
@@ -4,14 +4,14 @@ A lightweight package for validating JSON like Python objects.
|
|
|
4
4
|
|
|
5
5
|
## Schemas
|
|
6
6
|
|
|
7
|
-
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an [
|
|
7
|
+
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an example one may consult the [schema of the run object](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example1.md) in the mongodb database underlying the Fishtest web application <https://tests.stockfishchess.org/tests>.
|
|
8
8
|
|
|
9
9
|
The following conventions are used:
|
|
10
10
|
|
|
11
11
|
- As in typescript, a (string) key ending in `?` represents an optional key. The corresponding schema (the item the key points to) will only be used for validation when the key is present in the object that should be validated. A key can also be made optional by wrapping it as `optional_key(key)`.
|
|
12
12
|
- If in a list/tuple the last entry is `...` (ellipsis) it means that the next to last entry will be repeated zero or more times. In this way generic types can be created. For example the schema `[str, ...]` represents a list of strings.
|
|
13
13
|
|
|
14
|
-
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type
|
|
14
|
+
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type annotation. Here is the above example rewritten in a way that is [compatible with type annotations](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example2.md). E.g. if one wants to ensure that a run object obtained via an api has the correct type one can do
|
|
15
15
|
|
|
16
16
|
```python
|
|
17
17
|
from typing import assert_type
|
|
@@ -140,7 +140,7 @@ A schema can be, in order of precedence:
|
|
|
140
140
|
```
|
|
141
141
|
|
|
142
142
|
where the optional argument `_deferred_compiles` is an opaque data structure used for handling recursive schemas. If appropriate, the function `_compile` internally invokes the method `schema.__compile__` and this should produce an instance of the class `compiled_schema`. The method `__compile__` may invoke the function `_compile` again. If this happens then the optional argument `_deferred_compiles` should be passed unmodified. Please consult the source code of `vtjson` for more details.
|
|
143
|
-
- A Python type
|
|
143
|
+
- A Python type annotation such as `list[str]`. This is discussed further below.
|
|
144
144
|
- A Python type. In that case validation is done by checking membership. By convention the schema `float` matches both ints and floats. Similarly the schema `complex` matches ints and floats besides of course complex numbers.
|
|
145
145
|
- A callable. Validation is done by applying the callable to the object. If applying the callable throws an exception then the corresponding message will be part of the non-validation message.
|
|
146
146
|
- An instance of `Sequence` that is not an instance of `str` (e.g a `list` or a `tuple`). Validation is done by first checking membership of the schema type, and then performing validation for each of the entries of the object being validated against the corresponding entries of the schema.
|
|
@@ -148,7 +148,7 @@ A schema can be, in order of precedence:
|
|
|
148
148
|
- A `set`. A set validates an object if the object is a set and the elements of the object are validated by an element of the schema.
|
|
149
149
|
- An arbitrary Python object. Validation is done by checking equality of the schema and the object, except when the schema is `float`, in which case `math.isclose` is used. Below we call such an object a `const schema`.
|
|
150
150
|
|
|
151
|
-
## Validating Mapping
|
|
151
|
+
## Validating against Mapping schemas
|
|
152
152
|
|
|
153
153
|
For a Mapping schema containing only `const keys` (i.e. keys corresponding to a `const schema`) the interpretation is obvious (see the introductory example above). Below we discuss the validation of an object against a Mapping schema in the general case.
|
|
154
154
|
|
|
@@ -162,11 +162,11 @@ For a Mapping schema containing only `const keys` (i.e. keys corresponding to a
|
|
|
162
162
|
|
|
163
163
|
A consequence of this algorithm is that non-const keys are automatically optional. So applying the wrapper `optional_key` to them is meaningless and has no effect.
|
|
164
164
|
|
|
165
|
-
## Type
|
|
165
|
+
## Type annotations integration
|
|
166
166
|
|
|
167
|
-
### Type
|
|
167
|
+
### Type annotations as schemas
|
|
168
168
|
|
|
169
|
-
`vtjson` recognizes the following type
|
|
169
|
+
`vtjson` recognizes the following type annotations as schemas.
|
|
170
170
|
|
|
171
171
|
```python
|
|
172
172
|
Annotated, Mapping[...,...] and subtypes, Container[...] and subtypes,
|
|
@@ -174,14 +174,14 @@ tuple[...], Tuple[...], Protocol, NamedTuple, Literal, NewType, TypedDict,
|
|
|
174
174
|
Union (or the equivalent operator |), Any.
|
|
175
175
|
```
|
|
176
176
|
|
|
177
|
-
For example `
|
|
177
|
+
For example `dict[str, str]` is translated internally into the schema `{str: str}`. See below for more information.
|
|
178
178
|
|
|
179
179
|
### Annotated
|
|
180
180
|
|
|
181
|
-
- More general vtjson schemas can work along Python type
|
|
181
|
+
- More general vtjson schemas can work along Python type annotations by using the `typing.Annotated` contruct. The most naive way to do this is via
|
|
182
182
|
|
|
183
183
|
```python
|
|
184
|
-
Annotated[
|
|
184
|
+
Annotated[type_annotation, vtjson_schema, skip_first]
|
|
185
185
|
```
|
|
186
186
|
|
|
187
187
|
For example
|
|
@@ -190,8 +190,8 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
190
190
|
Annotated[list[object], [int, str, float], skip_first]
|
|
191
191
|
```
|
|
192
192
|
|
|
193
|
-
A type checker such as `mypy` will only see the type
|
|
194
|
-
- In some use cases a vtjon_schema will meaningfully refine a Python type or type
|
|
193
|
+
A type checker such as `mypy` will only see the type annotation (`list[object]` in the example), whereas vtjson will only see the vtjson schema (`[int, str, float]` in the example). `skip_first` is a built-in short hand for `Apply(skip_first=True)` (see below) which directs vtjson to ignore the first argument of an `Annotated` schema.
|
|
194
|
+
- In some use cases a vtjon_schema will meaningfully refine a Python type or type annotation. In that case one should not use `skip_first`. For example:
|
|
195
195
|
|
|
196
196
|
```python
|
|
197
197
|
Annotated[datetime, fields({"tzinfo": timezone.utc})]
|
|
@@ -206,18 +206,18 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
206
206
|
```
|
|
207
207
|
|
|
208
208
|
matches even integers.
|
|
209
|
-
- If one wants to pre-compile a schema and still use it as a type
|
|
209
|
+
- If one wants to pre-compile a schema and still use it as a type annotation (assuming it is valid as such) then one can do:
|
|
210
210
|
|
|
211
211
|
```python
|
|
212
212
|
schema = <schema definition>
|
|
213
213
|
Schema = Annotated[schema, compile(schema), skip_first]
|
|
214
214
|
```
|
|
215
215
|
|
|
216
|
-
### Supported type
|
|
216
|
+
### Supported type annotations
|
|
217
217
|
|
|
218
|
-
Note that Python imposes strong restrictions on what constitutes a valid type
|
|
218
|
+
Note that Python imposes strong restrictions on what constitutes a valid type annotation but `vtjson` is much more lax about this. Enforcing the restrictions is left to the type checkers or the Python interpreter.
|
|
219
219
|
|
|
220
|
-
- `TypedDict`. A TypedDict type
|
|
220
|
+
- `TypedDict`. A TypedDict type annotation is translated into a `dict` schema. E.g.
|
|
221
221
|
|
|
222
222
|
```python
|
|
223
223
|
class Movie(TypedDict):
|
|
@@ -253,9 +253,9 @@ Note that Python imposes strong restrictions on what constitutes a valid type hi
|
|
|
253
253
|
|
|
254
254
|
- `tuple[...]` and `Tuple[...]` are translated into the equivalent `tuple` schemas.
|
|
255
255
|
|
|
256
|
-
- `Mapping[
|
|
256
|
+
- `Mapping[S, T]` and subtypes validate those objects that are members of the origin type (a subclass of `Mapping`) and whose (key, value) pairs match `(S, T)`.
|
|
257
257
|
|
|
258
|
-
- `Container[
|
|
258
|
+
- `Container[T]` and subtypes validate those objects that are members of the origin type (a subclass of `Container`) and whose elements match `T`.
|
|
259
259
|
|
|
260
260
|
- `Union` and the `|` operator are translated into `union`.
|
|
261
261
|
|
|
@@ -289,7 +289,7 @@ Vtjson includes the command
|
|
|
289
289
|
safe_cast(schema, object)
|
|
290
290
|
```
|
|
291
291
|
|
|
292
|
-
(where `schema` should be a valid type
|
|
292
|
+
(where `schema` should be a valid type annotation) that functions exactly like `cast` except that it also verifies at run time that the given object matches the given schema.
|
|
293
293
|
|
|
294
294
|
## Creating types
|
|
295
295
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.1
|
|
2
2
|
Name: vtjson
|
|
3
|
-
Version: 2.1.
|
|
3
|
+
Version: 2.1.8
|
|
4
4
|
Summary: A lightweight package for validating JSON like Python objects
|
|
5
5
|
Author-email: Michel Van den Bergh <michel.vandenbergh@uhasselt.be>
|
|
6
6
|
Project-URL: Homepage, https://github.com/vdbergh/vtjson
|
|
@@ -24,14 +24,14 @@ A lightweight package for validating JSON like Python objects.
|
|
|
24
24
|
|
|
25
25
|
## Schemas
|
|
26
26
|
|
|
27
|
-
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an [
|
|
27
|
+
Validation of JSON like Python objects is done according to a `schema` which is somewhat inspired by a typescript type. The format of a schema is more or less self explanatory. As an example one may consult the [schema of the run object](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example1.md) in the mongodb database underlying the Fishtest web application <https://tests.stockfishchess.org/tests>.
|
|
28
28
|
|
|
29
29
|
The following conventions are used:
|
|
30
30
|
|
|
31
31
|
- As in typescript, a (string) key ending in `?` represents an optional key. The corresponding schema (the item the key points to) will only be used for validation when the key is present in the object that should be validated. A key can also be made optional by wrapping it as `optional_key(key)`.
|
|
32
32
|
- If in a list/tuple the last entry is `...` (ellipsis) it means that the next to last entry will be repeated zero or more times. In this way generic types can be created. For example the schema `[str, ...]` represents a list of strings.
|
|
33
33
|
|
|
34
|
-
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type
|
|
34
|
+
As of version 2.1, a suitable adapted `vtjson` schema can be used as a Python type annotation. Here is the above example rewritten in a way that is [compatible with type annotations](https://raw.githubusercontent.com/vdbergh/vtjson/refs/heads/main/docs/example2.md). E.g. if one wants to ensure that a run object obtained via an api has the correct type one can do
|
|
35
35
|
|
|
36
36
|
```python
|
|
37
37
|
from typing import assert_type
|
|
@@ -160,7 +160,7 @@ A schema can be, in order of precedence:
|
|
|
160
160
|
```
|
|
161
161
|
|
|
162
162
|
where the optional argument `_deferred_compiles` is an opaque data structure used for handling recursive schemas. If appropriate, the function `_compile` internally invokes the method `schema.__compile__` and this should produce an instance of the class `compiled_schema`. The method `__compile__` may invoke the function `_compile` again. If this happens then the optional argument `_deferred_compiles` should be passed unmodified. Please consult the source code of `vtjson` for more details.
|
|
163
|
-
- A Python type
|
|
163
|
+
- A Python type annotation such as `list[str]`. This is discussed further below.
|
|
164
164
|
- A Python type. In that case validation is done by checking membership. By convention the schema `float` matches both ints and floats. Similarly the schema `complex` matches ints and floats besides of course complex numbers.
|
|
165
165
|
- A callable. Validation is done by applying the callable to the object. If applying the callable throws an exception then the corresponding message will be part of the non-validation message.
|
|
166
166
|
- An instance of `Sequence` that is not an instance of `str` (e.g a `list` or a `tuple`). Validation is done by first checking membership of the schema type, and then performing validation for each of the entries of the object being validated against the corresponding entries of the schema.
|
|
@@ -168,7 +168,7 @@ A schema can be, in order of precedence:
|
|
|
168
168
|
- A `set`. A set validates an object if the object is a set and the elements of the object are validated by an element of the schema.
|
|
169
169
|
- An arbitrary Python object. Validation is done by checking equality of the schema and the object, except when the schema is `float`, in which case `math.isclose` is used. Below we call such an object a `const schema`.
|
|
170
170
|
|
|
171
|
-
## Validating Mapping
|
|
171
|
+
## Validating against Mapping schemas
|
|
172
172
|
|
|
173
173
|
For a Mapping schema containing only `const keys` (i.e. keys corresponding to a `const schema`) the interpretation is obvious (see the introductory example above). Below we discuss the validation of an object against a Mapping schema in the general case.
|
|
174
174
|
|
|
@@ -182,11 +182,11 @@ For a Mapping schema containing only `const keys` (i.e. keys corresponding to a
|
|
|
182
182
|
|
|
183
183
|
A consequence of this algorithm is that non-const keys are automatically optional. So applying the wrapper `optional_key` to them is meaningless and has no effect.
|
|
184
184
|
|
|
185
|
-
## Type
|
|
185
|
+
## Type annotations integration
|
|
186
186
|
|
|
187
|
-
### Type
|
|
187
|
+
### Type annotations as schemas
|
|
188
188
|
|
|
189
|
-
`vtjson` recognizes the following type
|
|
189
|
+
`vtjson` recognizes the following type annotations as schemas.
|
|
190
190
|
|
|
191
191
|
```python
|
|
192
192
|
Annotated, Mapping[...,...] and subtypes, Container[...] and subtypes,
|
|
@@ -194,14 +194,14 @@ tuple[...], Tuple[...], Protocol, NamedTuple, Literal, NewType, TypedDict,
|
|
|
194
194
|
Union (or the equivalent operator |), Any.
|
|
195
195
|
```
|
|
196
196
|
|
|
197
|
-
For example `
|
|
197
|
+
For example `dict[str, str]` is translated internally into the schema `{str: str}`. See below for more information.
|
|
198
198
|
|
|
199
199
|
### Annotated
|
|
200
200
|
|
|
201
|
-
- More general vtjson schemas can work along Python type
|
|
201
|
+
- More general vtjson schemas can work along Python type annotations by using the `typing.Annotated` contruct. The most naive way to do this is via
|
|
202
202
|
|
|
203
203
|
```python
|
|
204
|
-
Annotated[
|
|
204
|
+
Annotated[type_annotation, vtjson_schema, skip_first]
|
|
205
205
|
```
|
|
206
206
|
|
|
207
207
|
For example
|
|
@@ -210,8 +210,8 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
210
210
|
Annotated[list[object], [int, str, float], skip_first]
|
|
211
211
|
```
|
|
212
212
|
|
|
213
|
-
A type checker such as `mypy` will only see the type
|
|
214
|
-
- In some use cases a vtjon_schema will meaningfully refine a Python type or type
|
|
213
|
+
A type checker such as `mypy` will only see the type annotation (`list[object]` in the example), whereas vtjson will only see the vtjson schema (`[int, str, float]` in the example). `skip_first` is a built-in short hand for `Apply(skip_first=True)` (see below) which directs vtjson to ignore the first argument of an `Annotated` schema.
|
|
214
|
+
- In some use cases a vtjon_schema will meaningfully refine a Python type or type annotation. In that case one should not use `skip_first`. For example:
|
|
215
215
|
|
|
216
216
|
```python
|
|
217
217
|
Annotated[datetime, fields({"tzinfo": timezone.utc})]
|
|
@@ -226,18 +226,18 @@ For example `Mapping[str, str]` is translated internally into the schema `{str:
|
|
|
226
226
|
```
|
|
227
227
|
|
|
228
228
|
matches even integers.
|
|
229
|
-
- If one wants to pre-compile a schema and still use it as a type
|
|
229
|
+
- If one wants to pre-compile a schema and still use it as a type annotation (assuming it is valid as such) then one can do:
|
|
230
230
|
|
|
231
231
|
```python
|
|
232
232
|
schema = <schema definition>
|
|
233
233
|
Schema = Annotated[schema, compile(schema), skip_first]
|
|
234
234
|
```
|
|
235
235
|
|
|
236
|
-
### Supported type
|
|
236
|
+
### Supported type annotations
|
|
237
237
|
|
|
238
|
-
Note that Python imposes strong restrictions on what constitutes a valid type
|
|
238
|
+
Note that Python imposes strong restrictions on what constitutes a valid type annotation but `vtjson` is much more lax about this. Enforcing the restrictions is left to the type checkers or the Python interpreter.
|
|
239
239
|
|
|
240
|
-
- `TypedDict`. A TypedDict type
|
|
240
|
+
- `TypedDict`. A TypedDict type annotation is translated into a `dict` schema. E.g.
|
|
241
241
|
|
|
242
242
|
```python
|
|
243
243
|
class Movie(TypedDict):
|
|
@@ -273,9 +273,9 @@ Note that Python imposes strong restrictions on what constitutes a valid type hi
|
|
|
273
273
|
|
|
274
274
|
- `tuple[...]` and `Tuple[...]` are translated into the equivalent `tuple` schemas.
|
|
275
275
|
|
|
276
|
-
- `Mapping[
|
|
276
|
+
- `Mapping[S, T]` and subtypes validate those objects that are members of the origin type (a subclass of `Mapping`) and whose (key, value) pairs match `(S, T)`.
|
|
277
277
|
|
|
278
|
-
- `Container[
|
|
278
|
+
- `Container[T]` and subtypes validate those objects that are members of the origin type (a subclass of `Container`) and whose elements match `T`.
|
|
279
279
|
|
|
280
280
|
- `Union` and the `|` operator are translated into `union`.
|
|
281
281
|
|
|
@@ -309,7 +309,7 @@ Vtjson includes the command
|
|
|
309
309
|
safe_cast(schema, object)
|
|
310
310
|
```
|
|
311
311
|
|
|
312
|
-
(where `schema` should be a valid type
|
|
312
|
+
(where `schema` should be a valid type annotation) that functions exactly like `cast` except that it also verifies at run time that the given object matches the given schema.
|
|
313
313
|
|
|
314
314
|
## Creating types
|
|
315
315
|
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|