Re:STPyV8 – Python3 and JavaScript Interop with V8
by rvz on Tuesday December 31, 2019 @07:15PM
(#21925729)
> Other uses include squeezing in some "bare-metal" hyper-optimized (by V8) JavaScript into your Python projects, say as a stepping-stone to a full node.js port.
So we resort to having a double GC where one GC is present in Python and another one is in V8 which by reading this "use-case" sounds pretty strange for "bare-metal" applications which begs the question: Why?
There's a reason the deno project switched from Go to Rust to eliminate this problem and I don't see why using this library with Python + V8 for this type of use-case would make any sense.
Re:STPyV8 – Python3 and JavaScript Interop with V8
by randomfool on Wednesday January 01, 2020 @12:11AM
(#21926755)
Not just an issue for ‘bare metal’ applications- two GCs will be difficult for more complex scenarios as well where objects will have longer lifetimes spanning VMs.
This is a cool project that can definitely be useful, but those GC issues could rise up if you try a complex project and don’t design for them.
Re:STPyV8 – Python3 and JavaScript Interop with V8
by LeftHandPath on Tuesday December 31, 2019 @08:53PM
(#21926116)
This is full of weird examples. I take it it’s more useful for emulations than for use in any production environment.
> Calling methods on a JavaScript class from Python code...
This feels like an incomplete solution to a nonexistent problem.
JavaScript and Python can communicate however you want them to over a Unix or IP socket, which will ALWAYS be much lighter weight than running layered interpreters this way. All you need to do is determine a communication protocol and implement a basic API. Send a command, wait, and listen for a result.
> Wrapping a JavaScript function in a Python function...
There are other ways to skin that cat. And most of them are better.
We also maintain a mini_racer fork and regularly try to backport performance improvements upstream.
We also support alternative platforms such as Alpine/musl and Solaris. One of our main pain points is that the whole libv8 tooling/build system is ever changing and terribly self-serving to Google, so as much as we want to improve support for additional platforms upstream, it’s a tall order to have our hacks to build for those cleaned up and merged there.
So we resort to having a double GC where one GC is present in Python and another one is in V8 which by reading this "use-case" sounds pretty strange for "bare-metal" applications which begs the question: Why?
There's a reason the deno project switched from Go to Rust to eliminate this problem and I don't see why using this library with Python + V8 for this type of use-case would make any sense.
This is a cool project that can definitely be useful, but those GC issues could rise up if you try a complex project and don’t design for them.
> Calling methods on a JavaScript class from Python code...
This feels like an incomplete solution to a nonexistent problem.
JavaScript and Python can communicate however you want them to over a Unix or IP socket, which will ALWAYS be much lighter weight than running layered interpreters this way. All you need to do is determine a communication protocol and implement a basic API. Send a command, wait, and listen for a result.
> Wrapping a JavaScript function in a Python function...
There are other ways to skin that cat. And most of them are better.
Over here we have a high interest in running JS code efficiently within multiple host languages. To that end we ported Ruby’s mini_racer to Python.
https://github.com/sqreen/PyMiniRacer
We also maintain a mini_racer fork and regularly try to backport performance improvements upstream.
We also support alternative platforms such as Alpine/musl and Solaris. One of our main pain points is that the whole libv8 tooling/build system is ever changing and terribly self-serving to Google, so as much as we want to improve support for additional platforms upstream, it’s a tall order to have our hacks to build for those cleaned up and merged there.