About
Object-oriented JSONSchema
Key features
Traverse schema like paths
Access schema on demand with separate dereferencing accessor layer
Installation
pip install jsonschema-path
Alternatively you can download the code and install from the repository:
pip install -e git+https://github.com/p1c2u/jsonschema-path.git#egg=jsonschema_path
Usage
>>> from jsonschema_path import SchemaPath
>>> d = {
... "properties": {
... "info": {
... "$ref": "#/$defs/Info",
... },
... },
... "$defs": {
... "Info": {
... "properties": {
... "title": {
... "$ref": "http://example.com",
... },
... "version": {
... "type": "string",
... "default": "1.0",
... },
... },
... },
... },
... }
>>> path = SchemaPath.from_dict(d)
>>> # Stat keys
>>> "properties" in path
True
>>> # Concatenate paths with /
>>> info_path = path / "properties" / "info"
>>> # Stat keys with implicit dereferencing
>>> "properties" in info_path
True
>>> # Concatenate paths with implicit dereferencing
>>> version_path = info_path / "properties" / "version"
>>> # Open content with implicit dereferencing
>>> with version_path.open() as contents:
... print(contents)
{'type': 'string', 'default': '1.0'}
Identity and equality
Two SchemaPath instances are equal if they have the same parts and point to the same SchemaAccessor. SchemaAccessor identity is per-resource-handle: same wrapped dict (by reference), same base_uri, and same internal resolver instance. In practice:
Paths derived from the same accessor compare equal as expected:
>>> accessor = SchemaAccessor.from_schema(d) >>> SchemaPath(accessor) / "properties" == SchemaPath(accessor) / "properties" TruePaths from separate from_dict or from_schema calls do not compare equal even with identical arguments, because each call builds its own accessor:
>>> SchemaPath.from_dict(d) == SchemaPath.from_dict(d) FalseSchemaAccessor is hashable, so accessors and paths can be used as set members and dict keys.
This is also why the “build one accessor, reuse it” pattern below matters: it is both a caching optimisation and the contract you need for path equality to behave the way you expect.
Resolved cache
The resolved-path cache is intended for repeated path lookups and may significantly improve read_value/membership hot paths. When the underlying referencing registry grows (e.g. an external $ref pulls in a new document), cached entries are rebound to the new registry on read instead of being discarded. This relies on registries growing monotonically — resources are added, never replaced. Handlers that return drifting content for the same URI violate that assumption; disable caching with resolved_cache_maxsize=0 if you need to defend against it.
This cache is enabled by default (resolved_cache_maxsize=128). You can disable it when creating paths or accessors, for example:
>>> path = SchemaPath.from_dict(d, resolved_cache_maxsize=0)
Build one SchemaAccessor per schema document and reuse it for
every SchemaPath you derive from that document. Treat the accessor
as the long-lived handle to the resource; treat paths as cheap views over
it.
>>> from jsonschema_path import SchemaAccessor, SchemaPath
>>> # Construct the accessor once, with caching enabled.
>>> accessor = SchemaAccessor.from_schema(d, resolved_cache_maxsize=128)
>>> # Derive as many paths as you like from the same accessor.
>>> root = SchemaPath(accessor)
>>> info = root / "properties" / "info"
>>> version = info / "properties" / "version"
>>> # Every path over `accessor` shares the same resolved-ref cache.
>>> with version.open() as contents:
... ...
Benchmarks
Benchmarks mirror the lightweight (dependency-free) JSON output format used in pathable.
Run locally with Poetry:
poetry run python -m tests.benchmarks.bench_parse --output reports/bench-parse.json
poetry run python -m tests.benchmarks.bench_lookup --output reports/bench-lookup.json
For a quick smoke run:
poetry run python -m tests.benchmarks.bench_parse --output reports/bench-parse.quick.json --quick
poetry run python -m tests.benchmarks.bench_lookup --output reports/bench-lookup.quick.json --quick
You can also control repeats/warmup and resolved cache maxsize via env vars:
export JSONSCHEMA_PATH_BENCH_REPEATS=5
export JSONSCHEMA_PATH_BENCH_WARMUP=1
export JSONSCHEMA_PATH_BENCH_RESOLVED_CACHE_MAXSIZE=64
Compare two results:
poetry run python -m tests.benchmarks.compare_results \
--baseline reports/bench-lookup-master.json \
--candidate reports/bench-lookup.json \
--tolerance 0.20
License
Copyright (c) 2017-2025, Artur Maciag, All rights reserved. Apache-2.0
Release files for jsonschema-path 0.5.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| jsonschema_path-0.5.0.tar.gz | 19.6 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| jsonschema_path-0.5.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 43.7 kB
Release files / jsonschema_path-0.5.0.tar.gz
| Download URL | jsonschema_path-0.5.0.tar.gz |
|---|---|
| Size | 19.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
493b156ba895c97602655b620a8456caa2ce08c1aa389f5a7addec065e6e855c
|
|
BLAKE2b-256 checksum How to use checksums |
3979cd02a4df6d9270efdc7d3feefe6edd730b0820c39eeaa107a2faee8322d5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 19, 2026.
Transparency logRelease files / jsonschema_path-0.5.0-py3-none-any.whl
| Download URL | jsonschema_path-0.5.0-py3-none-any.whl |
|---|---|
| Size | 24.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
2790a070bc7abb08ea3dbe4d340ece4efadf639223001f020c7503229ba068e2
|
|
BLAKE2b-256 checksum How to use checksums |
042c9e69d73c4297508be9e3b64a970ea3971b3eb8db64ffc5802d40bd25981f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 19, 2026.
Transparency log