[Resending from the right address, sorry for dupes]
On May 3, 2019, at 5:16 AM, Hugh Fisher <hugo.fisher@gmail.com> wrote:
On Fri, May 3, 2019 at 5:14 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
If we do decide to do it, then we need to answer the second question. Passing a "context" argument around seems the best solution. That is how the Java JNI does it. It sounds like that's how Javascript VMs do it too. We don't need to get creative. Look at what other VMs do and copy the best idea.
How often does an extension / native method need to know what the current context is? I'd be happy to see global variables changed to accessor function calls. Not so happy if there's a context arg that has to be passed everywhere, even if I don't care about it.
The problem is: where would the accessor function get the state? A global variable or TLS. So you haven’t solved the problem.
(Old timers might remember the Xlib API. The first argument to every function was an XDisplay * dpy. 99.99% of applications only ran on a single display (1+ screens, keyboard, and mouse) but we had to store the display and pass it everywhere.)
Functions have arguments because the value might change. So if my extension / native method takes a context argument, is it OK for me to pass a different one internally?
I don’t see why not.
And we can’t stop extensions from doing the wrong thing, like storing the context in a global variable. But such extensions will fail under certain scenarios involving multiple interpreters in a process.
Eric
Something like
PyObject * Py_foo_function(PyContext * context, ...) { PyObject * bar = Py_different_function(some_other_context, ...)
This could happen deliberately or by accident. What kind of expectations will there be on changing the context argument?
--
cheers, Hugh Fisher
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org