fastjsonpatch 0.1.0__tar.gz → 0.1.2__tar.gz

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.1.2 (2026-10-11)
+
+Documentation only: the README now states only measured facts (including exactly
+which platforms CI tests), and its link to MAINTAINING.md works on PyPI. No code
+changes. (0.1.1 was tagged but not published.)
+
 ## 0.1.0 (2026-10-11)
 
 First release. Behaves like jsonpatch 1.34 with `make_patch`, `apply`/`apply_patch`

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/Cargo.lock

@@ -23,7 +23,7 @@ checksum = "4e7648175b45a9a48536d676f68d918270699102aa8dab5496df06904c914600"
 
 [[package]]
 name = "fastjsonpatch"
-version = "0.1.0"
+version = "0.1.2"
 dependencies = [
  "ahash",
  "pyo3",

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "fastjsonpatch"
-version = "0.1.0"
+version = "0.1.2"
 edition = "2024"
 description = "Rust core of the fastjsonpatch Python package"
 license = "BSD-3-Clause"

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: fastjsonpatch
-Version: 0.1.0
+Version: 0.1.2
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Developers
 Classifier: Operating System :: OS Independent
@@ -29,9 +29,9 @@ Project-URL: Repository, https://github.com/amzntiger/fastjsonpatch
 
 A drop-in, faster [jsonpatch](https://github.com/stefankoegl/python-json-patch)
 ([RFC 6902](https://www.rfc-editor.org/rfc/rfc6902) JSON Patch) for Python.
-`make_patch` and `apply` run in Rust and return the **same patches, the same documents
-and the same exceptions** as jsonpatch 1.34: typically 10-50x faster to make a patch
-and 6-15x faster to apply one.
+`make_patch` and `apply` run in Rust and return the **same patches and the same
+documents, and raise exceptions with the same types and messages,** as jsonpatch 1.34.
+In the benchmarks below, making a patch is 9-57x faster and applying one 6-27x faster.
 
 ```sh
 pip install fastjsonpatch
@@ -60,19 +60,18 @@ every Python from 3.12 on. The only dependency is `jsonpointer`.
 ## Why
 
 JSON Patch describes a change to a JSON document as a list of operations (`add`,
-`remove`, `replace`, `move`, `copy`, `test`). It is how HTTP `PATCH` requests,
-Kubernetes and many APIs express partial updates, and how tools store or send the
-difference between two versions of a document.
+`remove`, `replace`, `move`, `copy`, `test`). It is a media type for HTTP `PATCH`
+requests (`application/json-patch+json`), Kubernetes accepts it
+(`kubectl patch --type=json`), and it can store or send the difference between two
+versions of a document.
 
-jsonpatch is the standard Python implementation, and it is written in pure Python.
-That is fine for small documents, but the cost grows quickly:
+jsonpatch is written in pure Python. In the measurements below:
 
-- `make_patch` on a 10,000-record document takes about 300 ms (on a fast machine),
-  and diffing two Kubernetes OpenAPI specs (3.7 MB) takes about 140 ms.
-- `apply` deep-copies the whole document first, so even a one-operation patch on a
-  large document costs tens of milliseconds.
-- A web service that applies or computes a patch per request spends 40-75 µs on
-  each call, even for small resources.
+- `make_patch` on a 10,000-record document takes 290 ms, and diffing two Kubernetes
+  OpenAPI specs (3.7 MB and 3.8 MB) takes 136 ms.
+- `apply` deep-copies the whole document first, so a 3-operation patch on the
+  3.8 MB Kubernetes spec takes 71 ms, against 21 µs when applied in place.
+- Applying or computing a patch on a small REST resource takes 47-74 µs per call.
 
 fastjsonpatch keeps jsonpatch's behaviour exactly and moves these hot paths to Rust,
 so existing code gets faster without changes.
@@ -85,10 +84,10 @@ Real-world data:
 
 | scenario | size | jsonpatch | fastjsonpatch | speedup |
 |---|---|---|---|---|
-| Kubernetes OpenAPI v1.33 → v1.34: make_patch | 3.7 MB, 283 ops | 136.4 ms | 9.6 ms | **14x** |
+| Kubernetes OpenAPI v1.33 (3.7 MB) → v1.34 (3.8 MB): make_patch | 283 ops | 136.4 ms | 9.6 ms | **14x** |
 | Kubernetes OpenAPI v1.33 → v1.34: apply | 283 ops | 78.0 ms | 11.4 ms | **7x** |
-| 3-op patch on the 3.8 MB spec | | 71.1 ms | 10.1 ms | **7x** |
-| 3-op patch on the 3.8 MB spec, `in_place=True` | | 21.2 µs | 4.7 µs | **4x** |
+| 3-op patch on the v1.34 spec | 3.8 MB | 71.1 ms | 10.1 ms | **7x** |
+| 3-op patch on the v1.34 spec, `in_place=True` | 3.8 MB | 21.2 µs | 4.7 µs | **4x** |
 | PyPI metadata snapshots (8k records): make_patch | 2,487 ops | 255.2 ms | 12.1 ms | **21x** |
 | PyPI metadata snapshots: apply | 2,487 ops | 91.7 ms | 14.0 ms | **7x** |
 | REST resource, apply_patch per request | ×1000 | 47.4 ms | 7.5 ms | **6x** |
@@ -105,19 +104,20 @@ Synthetic records shaped like `{"id", "name", "score", "tags": [..], "meta": {..
 | 2k ints, insert 1 at front | 1 | 17.04 ms | 1.91 ms | **9x** | 581 µs | 21 µs | **27x** |
 | small config (200 keys), 1 edit | 1 | 1.98 ms | 35 µs | **57x** | 464 µs | 32 µs | **15x** |
 
-Python 3.14 made `copy.deepcopy` about 1.6x faster, so on 3.14 jsonpatch's `apply` on
-a large document is faster too and the gap shrinks to about 6x. `make_patch` is not
-affected. Run `python bench/compare.py` (from the source distribution) to measure on
+Python 3.14 made `copy.deepcopy` about 1.5x faster, so on 3.14 jsonpatch's `apply` on
+a large document is faster too; on the "10k records, 100 field edits" workload the
+`apply` speedup drops from about 11x to about 6x. The `make_patch` speedup stays about
+the same. Run `python bench/compare.py` (from the source distribution) to measure on
 your own machine.
 
 ## Why it is faster
 
 **make_patch.** jsonpatch walks both documents in Python and compares every scalar
-with `json.dumps(a) == json.dumps(b)`. That serialisation is about half of the
-runtime; the rest is `isinstance` checks against abstract base classes and path
-tuples rebuilt at every level. fastjsonpatch walks the documents in Rust over the
-CPython objects directly (no conversion to a Rust data structure), compares values
-natively with the same rules as the `json.dumps` comparison (`1`, `1.0` and `True`
+with `json.dumps(a) == json.dumps(b)`. Profiling the "10k records" workload with
+cProfile puts about 40% of the time in `json.dumps` and about a third in `isinstance`
+checks against abstract base classes (`MutableMapping`, `MutableSequence`).
+fastjsonpatch walks the documents in Rust over the CPython objects directly (no
+conversion to a Rust data structure), compares values natively with the same rules as the `json.dumps` comparison (`1`, `1.0` and `True`
 are all different, `-0.0 != 0.0`, NaN equals NaN), keeps the current path on a stack,
 and takes a single lockstep pass when two dicts have the same keys in the same order.
 It is a port of jsonpatch's `DiffBuilder`, so it produces the same operations in the
@@ -130,14 +130,14 @@ fastjsonpatch copies each dict and list with one C call and only recurses into v
 that are themselves containers; it keeps `deepcopy`'s semantics (shared and cyclic
 references are copied once) but skips the bookkeeping for containers referenced only
 once. It then resolves the paths and runs the operations without creating
-intermediate objects.
+`JsonPointer` or operation objects.
 
 ## Compatibility
 
 fastjsonpatch is jsonpatch's own module (BSD licensed) with three methods routed to
 Rust: `JsonPatch.__init__` (validation), `JsonPatch.from_diff` (`make_patch`) and
 `JsonPatch.apply` (`apply_patch`). Everything else is jsonpatch's code, so the public
-API is identical: `JsonPatch`, `make_patch`, `apply_patch`, `JsonPatch.from_string`,
+names are the same: `JsonPatch`, `make_patch`, `apply_patch`, `JsonPatch.from_string`,
 the operation classes, `DiffBuilder`, `multidict`, and the exceptions
 `JsonPatchException`, `InvalidJsonPatch`, `JsonPatchConflict`, `JsonPatchTestFailed`
 (with the same hierarchy, and `JsonPointerException` from jsonpointer).
@@ -151,8 +151,10 @@ Python code, so results never differ:
 - **apply**: works on plain dicts and lists. An operation that would fail, or that
   touches anything else, is run by the original operation classes before anything is
   mutated, so errors have the same type and message.
-- Subclasses of `JsonPatch` with custom `operations`, `pointer_cls` or `json_dumper`,
-  and patches that are not lists or tuples, use the original code.
+- `apply` and validation use the original code for a custom `pointer_cls`, a
+  subclass with custom `operations` or an overridden `_get_operation`, and patches
+  that are not lists or tuples. `make_patch` uses it for a custom `dumps=` or
+  `json_dumper`.
 
 Known differences:
 
@@ -162,13 +164,17 @@ Known differences:
 - A value that is not a dict, list or JSON scalar inside a document being applied to
   is copied with `copy.deepcopy` on its own, so aliasing between such values is not
   preserved.
+- `__version__` is fastjsonpatch's version, and jsonpatch's `__author__` and
+  `__website__` are not defined.
 
 `fastjsonpatch.__jsonpatch_version__` says which jsonpatch release the behaviour
 matches (currently `1.34`).
 
 ## How it is tested
 
-About 1,570 tests, run on every supported OS and Python version:
+About 1,570 tests. CI runs them with Python 3.12, 3.13 and 3.14 on Linux (x86_64 and
+aarch64, glibc), macOS (arm64 and x86_64) and Windows (x64); the musl wheels are built
+but not tested in CI:
 
 - **Parity:** random documents, mutations and patches (valid and invalid) run through
   both fastjsonpatch and jsonpatch 1.34, comparing the resulting patches and documents
@@ -190,7 +196,7 @@ pytest tests
 python bench/compare.py                # speed vs jsonpatch on this machine
 ```
 
-See [MAINTAINING.md](MAINTAINING.md) for releases and upkeep.
+See [MAINTAINING.md](https://github.com/amzntiger/fastjsonpatch/blob/main/MAINTAINING.md) for releases and upkeep.
 
 ## License
 

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/README.md

@@ -2,9 +2,9 @@
 
 A drop-in, faster [jsonpatch](https://github.com/stefankoegl/python-json-patch)
 ([RFC 6902](https://www.rfc-editor.org/rfc/rfc6902) JSON Patch) for Python.
-`make_patch` and `apply` run in Rust and return the **same patches, the same documents
-and the same exceptions** as jsonpatch 1.34: typically 10-50x faster to make a patch
-and 6-15x faster to apply one.
+`make_patch` and `apply` run in Rust and return the **same patches and the same
+documents, and raise exceptions with the same types and messages,** as jsonpatch 1.34.
+In the benchmarks below, making a patch is 9-57x faster and applying one 6-27x faster.
 
 ```sh
 pip install fastjsonpatch
@@ -33,19 +33,18 @@ every Python from 3.12 on. The only dependency is `jsonpointer`.
 ## Why
 
 JSON Patch describes a change to a JSON document as a list of operations (`add`,
-`remove`, `replace`, `move`, `copy`, `test`). It is how HTTP `PATCH` requests,
-Kubernetes and many APIs express partial updates, and how tools store or send the
-difference between two versions of a document.
+`remove`, `replace`, `move`, `copy`, `test`). It is a media type for HTTP `PATCH`
+requests (`application/json-patch+json`), Kubernetes accepts it
+(`kubectl patch --type=json`), and it can store or send the difference between two
+versions of a document.
 
-jsonpatch is the standard Python implementation, and it is written in pure Python.
-That is fine for small documents, but the cost grows quickly:
+jsonpatch is written in pure Python. In the measurements below:
 
-- `make_patch` on a 10,000-record document takes about 300 ms (on a fast machine),
-  and diffing two Kubernetes OpenAPI specs (3.7 MB) takes about 140 ms.
-- `apply` deep-copies the whole document first, so even a one-operation patch on a
-  large document costs tens of milliseconds.
-- A web service that applies or computes a patch per request spends 40-75 µs on
-  each call, even for small resources.
+- `make_patch` on a 10,000-record document takes 290 ms, and diffing two Kubernetes
+  OpenAPI specs (3.7 MB and 3.8 MB) takes 136 ms.
+- `apply` deep-copies the whole document first, so a 3-operation patch on the
+  3.8 MB Kubernetes spec takes 71 ms, against 21 µs when applied in place.
+- Applying or computing a patch on a small REST resource takes 47-74 µs per call.
 
 fastjsonpatch keeps jsonpatch's behaviour exactly and moves these hot paths to Rust,
 so existing code gets faster without changes.
@@ -58,10 +57,10 @@ Real-world data:
 
 | scenario | size | jsonpatch | fastjsonpatch | speedup |
 |---|---|---|---|---|
-| Kubernetes OpenAPI v1.33 → v1.34: make_patch | 3.7 MB, 283 ops | 136.4 ms | 9.6 ms | **14x** |
+| Kubernetes OpenAPI v1.33 (3.7 MB) → v1.34 (3.8 MB): make_patch | 283 ops | 136.4 ms | 9.6 ms | **14x** |
 | Kubernetes OpenAPI v1.33 → v1.34: apply | 283 ops | 78.0 ms | 11.4 ms | **7x** |
-| 3-op patch on the 3.8 MB spec | | 71.1 ms | 10.1 ms | **7x** |
-| 3-op patch on the 3.8 MB spec, `in_place=True` | | 21.2 µs | 4.7 µs | **4x** |
+| 3-op patch on the v1.34 spec | 3.8 MB | 71.1 ms | 10.1 ms | **7x** |
+| 3-op patch on the v1.34 spec, `in_place=True` | 3.8 MB | 21.2 µs | 4.7 µs | **4x** |
 | PyPI metadata snapshots (8k records): make_patch | 2,487 ops | 255.2 ms | 12.1 ms | **21x** |
 | PyPI metadata snapshots: apply | 2,487 ops | 91.7 ms | 14.0 ms | **7x** |
 | REST resource, apply_patch per request | ×1000 | 47.4 ms | 7.5 ms | **6x** |
@@ -78,19 +77,20 @@ Synthetic records shaped like `{"id", "name", "score", "tags": [..], "meta": {..
 | 2k ints, insert 1 at front | 1 | 17.04 ms | 1.91 ms | **9x** | 581 µs | 21 µs | **27x** |
 | small config (200 keys), 1 edit | 1 | 1.98 ms | 35 µs | **57x** | 464 µs | 32 µs | **15x** |
 
-Python 3.14 made `copy.deepcopy` about 1.6x faster, so on 3.14 jsonpatch's `apply` on
-a large document is faster too and the gap shrinks to about 6x. `make_patch` is not
-affected. Run `python bench/compare.py` (from the source distribution) to measure on
+Python 3.14 made `copy.deepcopy` about 1.5x faster, so on 3.14 jsonpatch's `apply` on
+a large document is faster too; on the "10k records, 100 field edits" workload the
+`apply` speedup drops from about 11x to about 6x. The `make_patch` speedup stays about
+the same. Run `python bench/compare.py` (from the source distribution) to measure on
 your own machine.
 
 ## Why it is faster
 
 **make_patch.** jsonpatch walks both documents in Python and compares every scalar
-with `json.dumps(a) == json.dumps(b)`. That serialisation is about half of the
-runtime; the rest is `isinstance` checks against abstract base classes and path
-tuples rebuilt at every level. fastjsonpatch walks the documents in Rust over the
-CPython objects directly (no conversion to a Rust data structure), compares values
-natively with the same rules as the `json.dumps` comparison (`1`, `1.0` and `True`
+with `json.dumps(a) == json.dumps(b)`. Profiling the "10k records" workload with
+cProfile puts about 40% of the time in `json.dumps` and about a third in `isinstance`
+checks against abstract base classes (`MutableMapping`, `MutableSequence`).
+fastjsonpatch walks the documents in Rust over the CPython objects directly (no
+conversion to a Rust data structure), compares values natively with the same rules as the `json.dumps` comparison (`1`, `1.0` and `True`
 are all different, `-0.0 != 0.0`, NaN equals NaN), keeps the current path on a stack,
 and takes a single lockstep pass when two dicts have the same keys in the same order.
 It is a port of jsonpatch's `DiffBuilder`, so it produces the same operations in the
@@ -103,14 +103,14 @@ fastjsonpatch copies each dict and list with one C call and only recurses into v
 that are themselves containers; it keeps `deepcopy`'s semantics (shared and cyclic
 references are copied once) but skips the bookkeeping for containers referenced only
 once. It then resolves the paths and runs the operations without creating
-intermediate objects.
+`JsonPointer` or operation objects.
 
 ## Compatibility
 
 fastjsonpatch is jsonpatch's own module (BSD licensed) with three methods routed to
 Rust: `JsonPatch.__init__` (validation), `JsonPatch.from_diff` (`make_patch`) and
 `JsonPatch.apply` (`apply_patch`). Everything else is jsonpatch's code, so the public
-API is identical: `JsonPatch`, `make_patch`, `apply_patch`, `JsonPatch.from_string`,
+names are the same: `JsonPatch`, `make_patch`, `apply_patch`, `JsonPatch.from_string`,
 the operation classes, `DiffBuilder`, `multidict`, and the exceptions
 `JsonPatchException`, `InvalidJsonPatch`, `JsonPatchConflict`, `JsonPatchTestFailed`
 (with the same hierarchy, and `JsonPointerException` from jsonpointer).
@@ -124,8 +124,10 @@ Python code, so results never differ:
 - **apply**: works on plain dicts and lists. An operation that would fail, or that
   touches anything else, is run by the original operation classes before anything is
   mutated, so errors have the same type and message.
-- Subclasses of `JsonPatch` with custom `operations`, `pointer_cls` or `json_dumper`,
-  and patches that are not lists or tuples, use the original code.
+- `apply` and validation use the original code for a custom `pointer_cls`, a
+  subclass with custom `operations` or an overridden `_get_operation`, and patches
+  that are not lists or tuples. `make_patch` uses it for a custom `dumps=` or
+  `json_dumper`.
 
 Known differences:
 
@@ -135,13 +137,17 @@ Known differences:
 - A value that is not a dict, list or JSON scalar inside a document being applied to
   is copied with `copy.deepcopy` on its own, so aliasing between such values is not
   preserved.
+- `__version__` is fastjsonpatch's version, and jsonpatch's `__author__` and
+  `__website__` are not defined.
 
 `fastjsonpatch.__jsonpatch_version__` says which jsonpatch release the behaviour
 matches (currently `1.34`).
 
 ## How it is tested
 
-About 1,570 tests, run on every supported OS and Python version:
+About 1,570 tests. CI runs them with Python 3.12, 3.13 and 3.14 on Linux (x86_64 and
+aarch64, glibc), macOS (arm64 and x86_64) and Windows (x64); the musl wheels are built
+but not tested in CI:
 
 - **Parity:** random documents, mutations and patches (valid and invalid) run through
   both fastjsonpatch and jsonpatch 1.34, comparing the resulting patches and documents
@@ -163,7 +169,7 @@ pytest tests
 python bench/compare.py                # speed vs jsonpatch on this machine
 ```
 
-See [MAINTAINING.md](MAINTAINING.md) for releases and upkeep.
+See [MAINTAINING.md](https://github.com/amzntiger/fastjsonpatch/blob/main/MAINTAINING.md) for releases and upkeep.
 
 ## License
 

{fastjsonpatch-0.1.0 → fastjsonpatch-0.1.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "fastjsonpatch"
-version = "0.1.0"
+version = "0.1.2"
 description = "Drop-in faster jsonpatch (RFC 6902): make_patch and apply in Rust"
 readme = "README.md"
 license = "BSD-3-Clause"