3 ms·

STPyV8 – Python3 and JavaScript Interop with V8

48 points by pthyme 7y ago

giancarlostoro 7y ago
Wonder what this plus Electron would look like. I know... I know... it sounds ridiculous, but if we're merging JS and Python as it is.... Why not?
- eigenvalue 7y ago
  Makes a lot of sense to me. Electron offers a lot more flexibility from a design standpoint if you don’t care for the look and feel of Qt5 or GTK.
rvz 7y ago
> 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.
- amelius 7y ago
  Probably because a GC is tightly coupled to the runtime system of a language, and using a different GC requires rewriting the entire interpreter.
- randomfool 7y ago
  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.
LeftHandPath 7y ago
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.
lloeki 7y ago
Interesting project, glad to see some movement there! 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 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.

48 points by pthyme 7y ago

Wonder what this plus Electron would look like. I know... I know... it sounds ridiculous, but if we're merging JS and Python as it is.... Why not?

eigenvalue 7y ago
Makes a lot of sense to me. Electron offers a lot more flexibility from a design standpoint if you don’t care for the look and feel of Qt5 or GTK.

rvz 7y ago

> 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.

amelius 7y ago
Probably because a GC is tightly coupled to the runtime system of a language, and using a different GC requires rewriting the entire interpreter.
randomfool 7y ago
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.

LeftHandPath 7y ago

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.

lloeki 7y ago

Interesting project, glad to see some movement there! 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 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.