jsonatapy 2.1.6__tar.gz → 2.2.1__tar.gz

jsonatapy-2.2.1/CHANGELOG.md

@@ -0,0 +1,172 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+
+## [2.2.1] - 2026-07-08
+
+> Same code as [2.1.7](#217---2026-07-08) below, renumbered. This project's release versions
+> track the jsonata-js major/minor version they target (patch numbers are independent — see
+> README). `2.1.7` incorrectly continued the old `2.1.x` patch series even though this release's
+> guardrails feature and signature-engine fixes target jsonata-js `2.2.0`/`2.2.1`; `2.1.7` is
+> superseded immediately by this release and should not be used.
+
+### Added
+- Guardrails: `timeout` (ms, error code `D1012`), `max_stack_depth` (error code `D1011`), and
+  `max_sequence_length` (error code `D2015`) keyword arguments on `compile()` and every
+  `evaluate*()` call, enforced consistently across all three execution engines (tree-walker,
+  compiled-expression fast path, bytecode VM). All default to `None` (unlimited) — no behavior
+  change unless configured. See [Guardrails](docs/api.md#guardrails). (jsonata-js 2.2.1 Phase 2, #56)
+- Documented the guardrails API in `docs/api.md`, `docs/usage.md`, and `docs/error-handling.md`
+  (previously shipped with accurate Python docstrings but no user-facing docs), and corrected
+  `docs/migration-from-js.md`'s stale claim that Python had no built-in timeout support.
+
+### Fixed
+- A deeply-nested expression (arithmetic chains, parenthesized/grouped expressions) no longer
+  crashes the whole process (previously a native stack overflow) — now raises a graceful `U1002`
+  error instead, via a depth guard in the parser and a second, defense-in-depth guard in the
+  post-parse AST pass.
+- `Instr::MakeArray`/`MakeObject`/`BlockEnd`'s bytecode operands (and `CallBuiltin`'s argument
+  count, and internal constant-pool bookkeeping) no longer silently produce wrong, truncated
+  results for oversized literals/blocks/calls (e.g. array literals with more than 65,535
+  elements) — such cases now fall back to the always-correct tree-walker instead.
+- `ast_transform.rs`'s depth-guard error messages no longer imply `%`/`@`/`#` ancestor-operator
+  usage (e.g. "...while resolving ancestor/path metadata") when the guard fires for any
+  sufficiently-nested expression, including plain arithmetic.
+- Release workflow now fails loudly on a fresh dispatch when the target version tag already
+  exists at a different commit, instead of silently reusing the wrong commit (#53).
+
+## [2.1.7] - 2026-07-08
+
+**Superseded by [2.2.1](#221---2026-07-08) above, published the same day.** This version was
+numbered following a simple patch-increment from `2.1.6` rather than this project's actual
+versioning policy (track jsonata-js's major/minor). It is fully functional and was not yanked —
+package registries don't allow deleting a published version — but `2.2.1` is the version that
+should be used going forward.
+
+### Added
+- Guardrails: `timeout` (ms, error code `D1012`), `max_stack_depth` (error code `D1011`), and
+  `max_sequence_length` (error code `D2015`) keyword arguments on `compile()` and every
+  `evaluate*()` call, enforced consistently across all three execution engines (tree-walker,
+  compiled-expression fast path, bytecode VM). All default to `None` (unlimited) — no behavior
+  change unless configured. See [Guardrails](docs/api.md#guardrails). (jsonata-js 2.2.1 Phase 2, #56)
+- Documented the guardrails API in `docs/api.md`, `docs/usage.md`, and `docs/error-handling.md`
+  (previously shipped with accurate Python docstrings but no user-facing docs), and corrected
+  `docs/migration-from-js.md`'s stale claim that Python had no built-in timeout support.
+
+### Fixed
+- A deeply-nested expression (arithmetic chains, parenthesized/grouped expressions) no longer
+  crashes the whole process (previously a native stack overflow) — now raises a graceful `U1002`
+  error instead, via a depth guard in the parser and a second, defense-in-depth guard in the
+  post-parse AST pass.
+- `Instr::MakeArray`/`MakeObject`/`BlockEnd`'s bytecode operands (and `CallBuiltin`'s argument
+  count, and internal constant-pool bookkeeping) no longer silently produce wrong, truncated
+  results for oversized literals/blocks/calls (e.g. array literals with more than 65,535
+  elements) — such cases now fall back to the always-correct tree-walker instead.
+- `ast_transform.rs`'s depth-guard error messages no longer imply `%`/`@`/`#` ancestor-operator
+  usage (e.g. "...while resolving ancestor/path metadata") when the guard fires for any
+  sufficiently-nested expression, including plain arithmetic.
+- Release workflow now fails loudly on a fresh dispatch when the target version tag already
+  exists at a different commit, instead of silently reusing the wrong commit (#53).
+
+## [2.1.6] - 2026-07-07
+
+### Added
+- `%` (parent-reference) and `@`/`#` (focus/index binding) operators.
+- jsonata-js 2.2.1 Phase 1: signature engine rewrite adding `+`/`-` arity support (#36).
+- Versioned documentation via `mike`, fixing a gh-pages deploy race (#39).
+
+### Fixed
+- Reference test-suite coverage gaps: loader fix, datetime picture-strings,
+  `formatInteger`/`parseInteger` (Phases 0-2), and array-constructor/`distinct` stragglers
+  (Phase 5, #44).
+- `release.yml` never actually built macOS wheels, due to a broken `actions/setup-python`
+  invocation (#41).
+- Several benchmark accuracy/fairness corrections (await `jsonata-js` calls properly, substantiate
+  pre-converted-data speedup claims, use clean CI-sourced numbers, use jsonata-python's `Context`
+  for fair repeated-eval timing) (#45, #46, #49, #50).
+
+### Changed
+- macOS temporarily dropped from the main release matrix pending a self-hosted runner fix (#45,
+  #47) — later restored via a self-hosted Mac Mini runner.
+
+## [2.1.5] - 2026-07-04
+
+### Fixed
+- Native stack overflow on deep recursion — replaced with a graceful, coded error (fixes #34).
+- Lambda IDs are now generated from a monotonic counter instead of an AST pointer address, fixing
+  a ~0.5%-frequency wrong-closure bug from id aliasing across recursive/repeated evaluation
+  (fixes #35).
+- Tree-walker missing-path/field access now correctly produces `Undefined` instead of `Null` in
+  the ~20 sites that predated the `Null`/`Undefined` distinction (fixes #32).
+- CI repairs following the default-branch rename to `main`; patched `RUSTSEC-2026-0097`.
+
+### Changed
+- Bumped `pyo3` to 0.29 and `rand` to 0.10.
+
+## [2.1.4] - 2026-03-22
+
+### Added
+- `cargo publish` step in the release workflow.
+
+### Fixed
+- Release workflow is now idempotent for version-bump and tag-creation steps.
+- Corrected an incorrect expected value in the `substring` test suite.
+
+## [2.1.3] - 2026-03-22
+
+> Versions 2.1.1 and 2.1.2 were bumped internally but never published as standalone tagged
+> releases — their changes are folded into this entry, the next version actually released.
+
+### Added
+- Bytecode VM (`compiler.rs` + `vm.rs`, "Phase 4") restored and wired into the Python execution
+  path, with Criterion benchmarks comparing it against the tree-walker.
+- `pyo3` made an optional dependency; Rust crate renamed to `jsonata-core` and published to
+  crates.io independently of the `jsonatapy` PyPI package.
+
+### Fixed
+- PyO3 0.28 compatibility (`PyObject` → `Py<PyAny>`).
+- Clippy deprecations and `cargo-deny` license-check failures.
+- Upgraded Pillow (dev/docs dependency) to 12.1.1 for a CVE fix.
+
+### Changed
+- Multiple benchmark documentation and accuracy corrections.
+
+## [2.1.0] - 2026-02-08
+
+### Added
+- Initial public release: Rust-based JSONata implementation targeting jsonata-js v2.1.0 semantics.
+- Full jsonata-js v2.1.0 reference test-suite compatibility.
+- Python bindings (PyO3), published as `jsonatapy` on PyPI.
+- Rust core, published as `jsonata-core` on crates.io.
+
+---
+
+## Reference Implementation Tracking
+
+This project tracks the [jsonata-js](https://github.com/jsonata-js/jsonata) reference implementation.
+
+**Current status:** Full test-suite compatibility with jsonata-js v2.1.0 (+3 commits). jsonata-js
+v2.2.1 compatibility work is in progress — Phase 1 (signature engine, `+`/`-` arity support) and
+Phase 2 (resource guardrails) are done; see
+`docs/superpowers/specs/2026-07-04-jsonata-2.2.1-design.md` for the authoritative, up-to-date
+status of this effort.
+
+### Version History
+- Target tracking v2.1.0 - Project initialization (2025-01-17)

{jsonatapy-2.1.6 → jsonatapy-2.2.1}/Cargo.lock

@@ -255,9 +255,9 @@ dependencies = [
 
 [[package]]
 name = "crossbeam-epoch"
-version = "0.9.18"
+version = "0.9.20"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "5b82ac4a3c2ca9c3460964f020e1402edd5753411d7737aa39c3714ad1b5420e"
+checksum = "2d6914041f254d6e9176c01941b21115dcfb7089e55135a35411081bd106ef3f"
 dependencies = [
  "crossbeam-utils",
 ]
@@ -483,7 +483,7 @@ dependencies = [
 
 [[package]]
 name = "jsonata-core"
-version = "2.1.6"
+version = "2.2.1"
 dependencies = [
  "base64",
  "chrono",

{jsonatapy-2.1.6 → jsonatapy-2.2.1}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "jsonata-core"
-version = "2.1.6"
+version = "2.2.1"
 edition = "2021"
 authors = ["txjmb <txjmb@users.noreply.github.com>"]
 description = "High-performance Rust implementation of JSONata query and transformation language"

{jsonatapy-2.1.6 → jsonatapy-2.2.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: jsonatapy
-Version: 2.1.6
+Version: 2.2.1
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License
@@ -47,10 +47,14 @@ Project-URL: Repository, https://github.com/txjmb/jsonata-core
 
 High-performance [JSONata](https://jsonata.org/) implementation in Rust, with Python bindings.
 
-> Much of this project was built with human guidance using Claude Code. There was no performant
-> JSONata implementation in Python, so the goal was to port JSONata to Rust (with a PyO3 wrapper
-> for Python) and see how fast it could go. The answer: faster than V8 for most expression
-> workloads, and faster than the next pure-Rust implementation.
+Much of this project was built using Claude Code with significant human oversight. There was no performant
+JSONata implementation in Python, so the goal was to port JSONata to Rust (with a PyO3 wrapper
+for Python) and see how fast it could go. The answer: faster than V8 for most expression
+workloads, and faster than the next pure-Rust implementation.
+
+Many, many thanks to the incredible work of all the maintainers of the [JSONata](https://github.com/jsonata-js/jsonata) reference library.  JSONata is a very powerful, well-designed, and useful language that has made an impact on many projects.  This project leverages their outstanding work to extend that capability to Python and Rust and would not be possible without that project.  The implementation in Rust was strongly influenced by their implementation.  The 1600+ tests they created provided the scaffolding and validation for all of this project.  This project will continue to follow and be a derivative of the reference project as the JSONata reference library evolves.
+
+Release versions will follow the reference jsonata-js project major and minor release numbers, but not necessarily patches.  This will make it easier for adopters of this library to understand each release's JSONata API compatibility.  As an example, 2.1.7 should be compliant with 2.1.x jsonata-js tests, but may have fixes specific to this library.  If a patch release for jsonata-js is relevant for this project, it will be included in a patch release that may or may not follow the patch numbers of the upstream project.
 
 [![Crates.io](https://img.shields.io/crates/v/jsonata-core.svg)](https://crates.io/crates/jsonata-core)
 [![PyPI version](https://badge.fury.io/py/jsonatapy.svg)](https://pypi.org/project/jsonatapy/)
@@ -91,10 +95,10 @@ let result = Evaluator::new().evaluate(&ast, &data)?;
 ```toml
 # Cargo.toml
 [dependencies]
-jsonata-core = "2.1.2"          # pure Rust, no Python dependency
+jsonata-core = "2.1.6"          # pure Rust, no Python dependency
 
 # Optional: disable SIMD for constrained targets
-jsonata-core = { version = "2.1.2", default-features = false }
+jsonata-core = { version = "2.1.6", default-features = false }
 ```
 
 ---
@@ -124,10 +128,10 @@ print(result)  # 2450
 
 # Pre-convert data once for maximum throughput
 data = jsonatapy.JsonataData(large_dataset)
-result = expr.evaluate_with_data(data)   # 4–15x faster than evaluate(dict)
+result = expr.evaluate_with_data(data)   # 3–15x faster than evaluate(dict)
 ```
 
-Supports Python 3.10, 3.11, 3.12, 3.13 on Linux, macOS (Intel & ARM), and Windows.
+Supports Python 3.10, 3.11, 3.12, 3.13, 3.14 on Linux, macOS (Intel & ARM), and Windows.
 
 ---
 
@@ -148,58 +152,25 @@ See [official JSONata docs](https://docs.jsonata.org/) for the full language ref
 ## Performance
 
 `jsonata-core` passes **1682/1682** JSONata reference tests and is the fastest JSONata
-implementation available in either Rust or Python.
-
-### Pure Rust (Criterion benchmarks, no Python overhead)
-
-| Category | jsonata-core | vs jsonata-rs |
-|----------|-------------|----------------|
-| Simple path lookup | 81 ns | ~40x faster |
-| Arithmetic expression | 140 ns | ~40x faster |
-| Conditional | 106 ns | ~30x faster |
-| String operations | 126–284 ns | ~30x faster |
-| $sum (100 elements) | 287 ns | ~70x faster |
-| Filter predicate (100 objects) | 7.9 µs | ~50x faster |
-| Realistic workload (100 products) | 9–44 µs | ~40x faster |
+implementation available in either Rust or Python:
 
-Run the benchmarks yourself:
-```bash
-cargo bench --no-default-features --features simd
-```
+- **~6x faster on average** than the JavaScript reference implementation (V8), across all
+  benchmark categories — up to ~16x for complex transformations and string operations
+- **~40x faster** than jsonata-rs (the next pure-Rust JSONata implementation) on pure-Rust
+  Criterion benchmarks with no Python overhead on either side (`cargo bench`)
+- **hundreds of times faster** than jsonata-python, even when it reuses its fastest
+  (`Context`-based) repeated-evaluation path
 
-### Python path (`jsonatapy`)
-
-`jsonatapy` is the fastest Python JSONata implementation by a large margin, and faster than
-the JavaScript reference implementation for most pure expression workloads:
-
-| Category | vs JavaScript (V8) | vs jsonata-python |
-|----------|--------------------|-------------------|
-| Simple paths | **5–8x faster** (array index access: roughly tied) | ~20–40x faster |
-| Conditionals | **15x faster** | ~40x faster |
-| String operations | **8–15x faster** | ~30–45x faster |
-| Complex transformations | **5–15x faster** | ~20–40x faster |
-| Higher-order functions | **12–19x faster** | ~50–70x faster |
-| Array-heavy workloads | **~1–3x slower to ~4x faster**, depending on access pattern | ~10–50x faster |
-
-### The Python boundary
-
-For large array workloads, the dominant cost is converting Python dicts to Rust values
-on each `evaluate()` call — not expression evaluation itself. Two API paths avoid this:
+For large array workloads, pre-convert data once with `jsonatapy.JsonataData` and reuse it
+across queries — this avoids the Python↔Rust conversion cost that otherwise dominates:
 
 ```python
-# Path 1: Pre-convert data once, reuse across many queries (4–15x faster than evaluate(dict))
 data = jsonatapy.JsonataData(large_dataset)
-result = expr.evaluate_with_data(data)
-
-# Path 2: Data arrives as a raw JSON string — pass it directly
-result_str = expr.evaluate_json(raw_json_string)
+result = expr.evaluate_with_data(data)   # 3–15x faster than evaluate(dict)
 ```
 
-With pre-converted data, realistic workloads (filtering, transforming, aggregating over
-100-object arrays) run **~5–8x faster than V8**, not slower — even the raw `evaluate(dict)`
-path without pre-conversion is roughly at parity with V8 (0.5–2x either direction).
-
-See [Performance docs](docs/performance.md) for full benchmark results and methodology.
+See [Performance docs](docs/performance.md) for the full category-by-category breakdown and
+benchmark methodology.
 
 ---
 
@@ -208,7 +179,7 @@ See [Performance docs](docs/performance.md) for full benchmark results and metho
 - **1682/1682 JSONata reference tests passing**
 - **Pure Rust core** — no JavaScript runtime, no Node.js dependency
 - **Optional Python bindings** — PyO3/maturin, zero-copy where possible
-- **Cross-platform** — Linux, macOS (Intel & ARM), Windows; Python 3.10–3.13
+- **Cross-platform** — Linux, macOS (Intel & ARM), Windows; Python 3.10–3.14
 - **SIMD-accelerated JSON parsing** — via `simd-json` (optional feature)
 
 ---

{jsonatapy-2.1.6 → jsonatapy-2.2.1}/README.md

@@ -2,10 +2,14 @@
 
 High-performance [JSONata](https://jsonata.org/) implementation in Rust, with Python bindings.
 
-> Much of this project was built with human guidance using Claude Code. There was no performant
-> JSONata implementation in Python, so the goal was to port JSONata to Rust (with a PyO3 wrapper
-> for Python) and see how fast it could go. The answer: faster than V8 for most expression
-> workloads, and faster than the next pure-Rust implementation.
+Much of this project was built using Claude Code with significant human oversight. There was no performant
+JSONata implementation in Python, so the goal was to port JSONata to Rust (with a PyO3 wrapper
+for Python) and see how fast it could go. The answer: faster than V8 for most expression
+workloads, and faster than the next pure-Rust implementation.
+
+Many, many thanks to the incredible work of all the maintainers of the [JSONata](https://github.com/jsonata-js/jsonata) reference library.  JSONata is a very powerful, well-designed, and useful language that has made an impact on many projects.  This project leverages their outstanding work to extend that capability to Python and Rust and would not be possible without that project.  The implementation in Rust was strongly influenced by their implementation.  The 1600+ tests they created provided the scaffolding and validation for all of this project.  This project will continue to follow and be a derivative of the reference project as the JSONata reference library evolves.
+
+Release versions will follow the reference jsonata-js project major and minor release numbers, but not necessarily patches.  This will make it easier for adopters of this library to understand each release's JSONata API compatibility.  As an example, 2.1.7 should be compliant with 2.1.x jsonata-js tests, but may have fixes specific to this library.  If a patch release for jsonata-js is relevant for this project, it will be included in a patch release that may or may not follow the patch numbers of the upstream project.
 
 [![Crates.io](https://img.shields.io/crates/v/jsonata-core.svg)](https://crates.io/crates/jsonata-core)
 [![PyPI version](https://badge.fury.io/py/jsonatapy.svg)](https://pypi.org/project/jsonatapy/)
@@ -46,10 +50,10 @@ let result = Evaluator::new().evaluate(&ast, &data)?;
 ```toml
 # Cargo.toml
 [dependencies]
-jsonata-core = "2.1.2"          # pure Rust, no Python dependency
+jsonata-core = "2.1.6"          # pure Rust, no Python dependency
 
 # Optional: disable SIMD for constrained targets
-jsonata-core = { version = "2.1.2", default-features = false }
+jsonata-core = { version = "2.1.6", default-features = false }
 ```
 
 ---
@@ -79,10 +83,10 @@ print(result)  # 2450
 
 # Pre-convert data once for maximum throughput
 data = jsonatapy.JsonataData(large_dataset)
-result = expr.evaluate_with_data(data)   # 4–15x faster than evaluate(dict)
+result = expr.evaluate_with_data(data)   # 3–15x faster than evaluate(dict)
 ```
 
-Supports Python 3.10, 3.11, 3.12, 3.13 on Linux, macOS (Intel & ARM), and Windows.
+Supports Python 3.10, 3.11, 3.12, 3.13, 3.14 on Linux, macOS (Intel & ARM), and Windows.
 
 ---
 
@@ -103,58 +107,25 @@ See [official JSONata docs](https://docs.jsonata.org/) for the full language ref
 ## Performance
 
 `jsonata-core` passes **1682/1682** JSONata reference tests and is the fastest JSONata
-implementation available in either Rust or Python.
-
-### Pure Rust (Criterion benchmarks, no Python overhead)
-
-| Category | jsonata-core | vs jsonata-rs |
-|----------|-------------|----------------|
-| Simple path lookup | 81 ns | ~40x faster |
-| Arithmetic expression | 140 ns | ~40x faster |
-| Conditional | 106 ns | ~30x faster |
-| String operations | 126–284 ns | ~30x faster |
-| $sum (100 elements) | 287 ns | ~70x faster |
-| Filter predicate (100 objects) | 7.9 µs | ~50x faster |
-| Realistic workload (100 products) | 9–44 µs | ~40x faster |
+implementation available in either Rust or Python:
 
-Run the benchmarks yourself:
-```bash
-cargo bench --no-default-features --features simd
-```
+- **~6x faster on average** than the JavaScript reference implementation (V8), across all
+  benchmark categories — up to ~16x for complex transformations and string operations
+- **~40x faster** than jsonata-rs (the next pure-Rust JSONata implementation) on pure-Rust
+  Criterion benchmarks with no Python overhead on either side (`cargo bench`)
+- **hundreds of times faster** than jsonata-python, even when it reuses its fastest
+  (`Context`-based) repeated-evaluation path
 
-### Python path (`jsonatapy`)
-
-`jsonatapy` is the fastest Python JSONata implementation by a large margin, and faster than
-the JavaScript reference implementation for most pure expression workloads:
-
-| Category | vs JavaScript (V8) | vs jsonata-python |
-|----------|--------------------|-------------------|
-| Simple paths | **5–8x faster** (array index access: roughly tied) | ~20–40x faster |
-| Conditionals | **15x faster** | ~40x faster |
-| String operations | **8–15x faster** | ~30–45x faster |
-| Complex transformations | **5–15x faster** | ~20–40x faster |
-| Higher-order functions | **12–19x faster** | ~50–70x faster |
-| Array-heavy workloads | **~1–3x slower to ~4x faster**, depending on access pattern | ~10–50x faster |
-
-### The Python boundary
-
-For large array workloads, the dominant cost is converting Python dicts to Rust values
-on each `evaluate()` call — not expression evaluation itself. Two API paths avoid this:
+For large array workloads, pre-convert data once with `jsonatapy.JsonataData` and reuse it
+across queries — this avoids the Python↔Rust conversion cost that otherwise dominates:
 
 ```python
-# Path 1: Pre-convert data once, reuse across many queries (4–15x faster than evaluate(dict))
 data = jsonatapy.JsonataData(large_dataset)
-result = expr.evaluate_with_data(data)
-
-# Path 2: Data arrives as a raw JSON string — pass it directly
-result_str = expr.evaluate_json(raw_json_string)
+result = expr.evaluate_with_data(data)   # 3–15x faster than evaluate(dict)
 ```
 
-With pre-converted data, realistic workloads (filtering, transforming, aggregating over
-100-object arrays) run **~5–8x faster than V8**, not slower — even the raw `evaluate(dict)`
-path without pre-conversion is roughly at parity with V8 (0.5–2x either direction).
-
-See [Performance docs](docs/performance.md) for full benchmark results and methodology.
+See [Performance docs](docs/performance.md) for the full category-by-category breakdown and
+benchmark methodology.
 
 ---
 
@@ -163,7 +134,7 @@ See [Performance docs](docs/performance.md) for full benchmark results and metho
 - **1682/1682 JSONata reference tests passing**
 - **Pure Rust core** — no JavaScript runtime, no Node.js dependency
 - **Optional Python bindings** — PyO3/maturin, zero-copy where possible
-- **Cross-platform** — Linux, macOS (Intel & ARM), Windows; Python 3.10–3.13
+- **Cross-platform** — Linux, macOS (Intel & ARM), Windows; Python 3.10–3.14
 - **SIMD-accelerated JSON parsing** — via `simd-json` (optional feature)
 
 ---

{jsonatapy-2.1.6 → jsonatapy-2.2.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "jsonatapy"
-version = "2.1.6"
+version = "2.2.1"
 description = "High-performance Python/Rust implementation of JSONata query and transformation language"
 authors = [
     {name = "txjmb", email = "txjmb@users.noreply.github.com"}