Filterx function path lookup
Add path_lookup to the filterx_object Namespace as an Alternative to get_subscript
This PR introduces a new function, path_lookup, to the filterx_object namespace. It allows retrieving elements from nested filterx lists or dictionaries in a single call, providing a more convenient and expressive alternative to using get_subscript repeatedly.
Key Features:
- Flexible First Argument: The first argument must be a list or dictionary. Mixed structures (e.g., nested combinations of lists and dictionaries) are fully supported.
- Dynamic Path Lookup: The second parameter accepts a list literal containing both filterx strings (for dictionary keys) and integers (for list indices).
- Deep Nested Access: Enables seamless access to deeply nested elements in hybrid list-dictionary structures.
- Reverse Indexing Support: Integer indices support negative values for reverse indexing in lists, mirroring Python-like behavior.
example:
filterx {
d = {"foo":1,"bar":[3,2,1],"baz":{"tik":"tak"}};
a = path_lookup(d, ["bar", 0]); # returns 3
b = path_lookup(d, ["baz", "tik"]); # returns "tak"
c = path_lookup(d, ["bar", -1]); # returns 1
}
It would be great if we could delegate literal/string only paths to the underlying FilterXObject for an improved performance.
e.g. instead of just a getattr method, we would have a getpath method as well, which by default would implement the "generic" path_lookup case as you implemented it, but we would have an option to delegate it to the underlying object.
The ultimate goal would be to avoid having to wrap/unwrap the embedded JSON objects as return values, we could just iterate over string keys within object-json-object.c and then return the end result.
There's just one thing we should consider, #385 seems to improve the time to return embedded dict objects, if that proves to be a good substitute, then the existing series of getattr calls should not be a problem that much anymore.
#746 introduces the setter side with a different syntax. We should implement the getter side later based on this PR, but following the new syntax.
pyth