Repository navigation
Hash "#" prefix? #84
Description
Can you explain what the hash prefix does and how you intend it to work? I've got all but 3 tests in test_json_pointer.py passing. But I'm not exactly sure how the hash symbol is supposed to work. Can you explain this test case?
def test_non_standard_index_pointer() -> None:
data = {"foo": {"bar": [1, 2, 3], "#baz": "hello"}}
assert JSONPointer("/foo/bar/#1").resolve(data) == 1
with pytest.raises(JSONPointerIndexError):
JSONPointer("/foo/bar/#9").resolve(data)
Activity
jg-rp commentedon Aug 2, 2025
The hash prefix is there to point to an object (aka dict/map) key instead of the value associated with the key, or an array (aka list/sequence) index instead of the value at that index.
The Relative JSON Pointer draft spec supports this kind of operation. By adding this
#syntax to the JSON Pointer spec we guarantee that callingRelativeJSONPointer.to(some_json_pointer)will always return a usable instance ofJSONPointer.Here we're asserting that if
data["foo"]["bar"]is an array with something at index1, we just get the1back, regardless of the value at index1. If we were to resolve"/foo/bar/1"(same but without the hash) against the same data, we'd get2.And here we're checking that pointing to an out of bounds index raises an exception. This is the same behavior with or without a hash.
Note that we have a similar situation with the non-standard
keys_selector. It is there to ensure aJSONPathMatchcan always be coerced to an instance ofJSONPointerusing class methodJSONPointer.from_match().There's plenty of room for improvement in
pointer.py. At the very least I'd like to separate non-standard behavior into one or more subclasses ofJSONPointer, so users can choose to stick to RFC 6901.rob-ross commentedon Aug 2, 2025
So to summarize:
Arrays:
#n just returns
n, as long as the array has an element at [n]Throws a JSONPointerIndexError if element [n] does not exist
Objects:
#foo returns
fooif a ["foo"] key existsThrows a JSONPointerKeyError if key ["foo"] does not exist.
Is this accurate?
Also, this:
Is intended to fail with a
JSONPointerTypeError: pointer type error 01: list indices must be integers or slices, not strBut the following currently succeeds. Perhaps this is a bug?
jg-rp commentedon Aug 3, 2025
Yep, that's accurate. Unless an object has a key that actually starts with a hash. In which case we resolve the key to its associated value.
Yes, I'd call that a bug. We should follow the "digits without a leading '0'" policy from RFC 6901.