4 ms·

Racket has this for C-based APIs. My mind is kind of wondering how this would ever be stable/maintainable to use for Python, but Lua seems possible but I would

Racket has this for C-based APIs. My mind is kind of wondering how this would ever be stable/maintainable to use for Python, but Lua seems possible but I would rather do my scripting in Racket then Lua and use the C APIs directly. https://docs.racket-lang.org/foreign/index.html https://docs.racket-lang.org/foreign/index.html Looking at Julia (Which has a no "boiler plate" philosophy when using C or Fortan) the function is just called. Interesting to look at for comparison Julia ccall- https://docs.julialang.org/en/v0.6.1/manual/calling-c-and-fortran-code/ https://docs.julialang.org/en/v0.6.1/manual/calling-c-and-fo... Racket FFI - https://docs.racket-lang.org/foreign/index.html https://docs.racket-lang.org/foreign/index.html

guenchi 8y ago
I am researching julia's code. https://github.com/JuliaPy/PyCall.jl/blob/master/src/PyCall.jl https://github.com/JuliaPy/PyCall.jl/blob/master/src/PyCall.... I guess it is like this: Importing the pycall library is to turn on the python interpreter thread and not interrupt it. Then you can call any python library you want.
- blattimwind 8y ago
  The GIL is mostly managed by CPython and the host application doesn't touch it directly. Host extension modules may use PyEval_SaveThread et al. just like regular extension modules to release the GIL during blocking operations when called by CPython. There is a separate API for fondling the GIL when you're in a host-created thread (not created by CPython) and want to call CPython. Those are orthogonal (called by CPython vs. calling CPython).
blattimwind 8y ago
> My mind is kind of wondering how this would ever be stable/maintainable to use for Python CPython has a stable C API for interacting with the interpreter and Python objects. Presumably FLI goes through this API to interoperate with Python, just like any C/C++ application embedding CPython would. Edit: Yep, https://github.com/guenchi/FLI/blob/master/pycall.sc https://github.com/guenchi/FLI/blob/master/pycall.sc
- guenchi 8y ago
  Yes, it embeds the python interpreter into Scheme via C-api.

guenchi 8y ago

I am researching julia's code. https://github.com/JuliaPy/PyCall.jl/blob/master/src/PyCall.jl https://github.com/JuliaPy/PyCall.jl/blob/master/src/PyCall.... I guess it is like this: Importing the pycall library is to turn on the python interpreter thread and not interrupt it. Then you can call any python library you want.

blattimwind 8y ago
The GIL is mostly managed by CPython and the host application doesn't touch it directly. Host extension modules may use PyEval_SaveThread et al. just like regular extension modules to release the GIL during blocking operations when called by CPython. There is a separate API for fondling the GIL when you're in a host-created thread (not created by CPython) and want to call CPython. Those are orthogonal (called by CPython vs. calling CPython).

blattimwind 8y ago

> My mind is kind of wondering how this would ever be stable/maintainable to use for Python CPython has a stable C API for interacting with the interpreter and Python objects. Presumably FLI goes through this API to interoperate with Python, just like any C/C++ application embedding CPython would. Edit: Yep, https://github.com/guenchi/FLI/blob/master/pycall.sc https://github.com/guenchi/FLI/blob/master/pycall.sc

guenchi 8y ago
Yes, it embeds the python interpreter into Scheme via C-api.