As it stands, the usefulness of Proxy objects as passed to Python is somewhat limited. They all map to the foreign class, and AFAICT there's often no way to tell them apart short of randomly attempting to call methods that are known to behave differently for different Proxy classes and seeing if/which exceptions are thrown.
I'm passing 'simple' data structures (i.e. ones that can be JSON-serialized) to Python from Java as Proxy objects, and I'd like these to behave like 'normal' Python objects (ideally they should be indistinguishable from what I'd get by JSON-serializing the data in Java and calling json.loads() on it in Python). To get this behavior currently, I have to manually eval some Python translation code (which some iffy exception-based 'type checks' as outlined above) to replace the foreign values with proper Python equivalents. Since this has to happen both for bindings and function (ProxyExecutable) return values, it ends up complicating my code quite a bit, as well as slowing things down.
I wouldn't have to do any of this work if the Proxy types acted as their corresponding Python builtins by default. It seems to me like:
ProxyHashMap should act as a dict.
ProxyArray should act as an array.
ProxyObject should act as a plain old class.
Since Python is duck-typed, it should be relatively straightforward to make these types act as their Python equivalents by simply implementing the relevant attributes.
Looking at the built-in attributes of the aforementioned Python types, we see (Python 3.9.7):
For the Proxy types, dir() returns nothing (except for ProxyObject, where it returns the provided methods but none of the __ attributes). (It seems like some of these methods are still implemented (so __dir__ isn't working quite right) — for example __str__ works as expected for ProxyArray, and it exists for ProxyHashMap but doesn't print the actual map.)
Implementing (most of) these functions on the relevant proxy objects doesn't seem like it'd be that difficult, and would go a long way towards making graalpython more user-friendly!
As it stands, the usefulness of Proxy objects as passed to Python is somewhat limited. They all map to the
foreign
class, and AFAICT there's often no way to tell them apart short of randomly attempting to call methods that are known to behave differently for different Proxy classes and seeing if/which exceptions are thrown.I'm passing 'simple' data structures (i.e. ones that can be JSON-serialized) to Python from Java as Proxy objects, and I'd like these to behave like 'normal' Python objects (ideally they should be indistinguishable from what I'd get by JSON-serializing the data in Java and calling
json.loads()
on it in Python). To get this behavior currently, I have to manually eval some Python translation code (which some iffy exception-based 'type checks' as outlined above) to replace the foreign values with proper Python equivalents. Since this has to happen both for bindings and function (ProxyExecutable) return values, it ends up complicating my code quite a bit, as well as slowing things down.I wouldn't have to do any of this work if the Proxy types acted as their corresponding Python builtins by default. It seems to me like:
ProxyHashMap
should act as a dict.ProxyArray
should act as an array.ProxyObject
should act as a plain old class.Since Python is duck-typed, it should be relatively straightforward to make these types act as their Python equivalents by simply implementing the relevant attributes.
Looking at the built-in attributes of the aforementioned Python types, we see (Python 3.9.7):
For the Proxy types,
dir()
returns nothing (except for ProxyObject, where it returns the provided methods but none of the__
attributes). (It seems like some of these methods are still implemented (so__dir__
isn't working quite right) — for example__str__
works as expected for ProxyArray, and it exists forProxyHashMap
but doesn't print the actual map.)Implementing (most of) these functions on the relevant proxy objects doesn't seem like it'd be that difficult, and would go a long way towards making graalpython more user-friendly!
P.S. thanks for this awesome project!