https://pantsbuild.org/ logo
Join Slack
Powered by
I wonder whether <https://github.com/rust-lang/rus...
# development
a
I wonder whether https://github.com/rust-lang/rust/pull/58057/ will do anything for us... I'm guessing not particularly...
a
more inlining across generated C code + whatever python headers we pull in sounds like a potential perf opportunity but i don't know exactly what kind of code cffi/libffi uses to glue things together so not sure if that will matter
w
the C portion of cffi is relatively thin
but if we were to directly embed the python interpreter via https://github.com/pantsbuild/pants/issues/7369 ...
a
hmmmmmmmmmmmmmmmmmmmm
if we were to embed the python interpreter by building from source and/or using LTO that could at the very least remove any perf concerns about calls across ffi boundaries
a
There would still be perf concerns around e.g. the GIL. But yeah, an interesting corner…
w
there are a lot of potentials in these areas... i've played with https://github.com/PyO3/pyo3, and it seemed quite solid. with the (very significant) downside that it requires nightly
https://github.com/RustPython/RustPython is also a thing, although still with a GIL, and probably ages from being able to run 
setuptools
(wonder whether anyone has tried...)
and then, there's always starlark.
(oh, um... i think pyO3 removed support for python2 in the weeks since i last looked at it... probably for the best)
also not sure whether it supports static linking.
a
i would love to use starlark wherever it benefits us which it seems like could be a lot of places
i would also like to implement the bazel build api so we can consume bazel rules either through a specific FFI (from python to starlark) or 1:1 with v2 rules
Open in Slack
PreviousNext
Powered by