Recheck PyObject.callMethod/call semantics, review other options #2793
Comments
niloc132
added a commit
that referenced
this issue
Sep 1, 2022
) Reworks how we handle logging between Java and Python, giving Python code more control over and more visibility into the stdout and stderr streams. These changes also make it possible to see the same logs in both the web UI and the python terminal, in the case of DHaaL from Python. Follow-up is required to address some inefficiency around PyObject's tools for calling methods, see #2793. For #2723, jpy-consortium/jpy#85 is also required, to deal with zero-length bytestrings. Fixes #2734 Partial #2723
pete-petey
modified the milestones:
August 2023,
2023 tickets than need to be 'milestone-ed' and assigned
pete-petey
modified the milestones:
Year 2023 tickets that need to be 'milestone-ed' and assigned,
5. Backlog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After jpy-consortium/jpy#87 is resolved, revisit usages of PyObject (such as can be found in #2763), and check our callMethod/call semantics. We may find that some usages need not be so generic, and can be replaced by proxy usage as well.
For example,
PyObject.call("__call__", ...)is explicitly invoking the__call__method on a Callable instance. If I understand this correctly, and it is actually a method and not a function that happens to be assigned to the instance, this is supposed to be acallMethodinvocation despite being used to call a Callable.If JPy enhances its
callMethodand possible offers more powerful python proxy support, we can probably improve/replace many of these cases to avoid extra work done by the developer to make the call and extra objects for the runtime to deal with.The text was updated successfully, but these errors were encountered: