
STPyV8 – Python3 and JavaScript Interop with V8 - pthyme
https://github.com/area1/stpyv8
======
rvz
> 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.

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

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

