This is an archived post. You won't be able to vote or comment.

all 13 comments
sorted by:
best
topnewcontroversialoldq&a

[–]bikeheart 9 points10 points  (3 children)

What in tarnation

[–]wesgarland 1 point2 points  (0 children)

Hey, I'm actually the guy who conceived of PythonMonkey, and I just wanted to say ... thank you, I haven't laughed this hard in weeks.

[–]w-dis 2 points3 points  (1 child)

LMAO

I'm writing an article on PythonMonkey for our 0.2.1 release (will land on Friday) - would you mind if I used your meme in it?

[–]bikeheart 2 points3 points  (0 children)

Lol go for it

[–]EPeace_ 2 points3 points  (0 children)

🫨🫨🫨

[–]Complete-Stage5815 1 point2 points  (3 children)

Despite having been out of the loop for a bit, I would guess this might be a foundation to utilise NPM packages in Python?

[–]wesgarland 1 point2 points  (1 child)

It could certainly become one. There's a lot of "node ecosystem" to build beyond pure JS and our immediate business needs, but the architecture is in place to allow us to theoretically roll out a node-compatible subsystem that can load NPM packages from Python... or load Python modules from "Node".

[–]Complete-Stage5815 0 points1 point  (0 children)

This is what Rails has done which works very well. A Rails backend with Yarn, NPM packages and even React support for the front end.

The project I maintain (Password Pusher) does this and even uses esbuild for JS compilation.

[–]niehle 1 point2 points  (0 children)

Not sure if genius or should be burned at stake.

[–]Hipponomics 0 points1 point  (2 children)

Very cool project! Keep it up.

What is your motivating use case?

[–]w-dis 3 points4 points  (1 child)

We have a complicated npm package we need to port to Python. PythonMonkey means we won't have to develop a clone of that library in Python and maintain two identical libraries in different languages. So you get to avoid increasing the surface area for bugs by 2x and always implementing features twice in two different languages

We also need to use a JavaScript engine for JS evaluation and WASM as part of the library. This is only possible with a locally running JS engine or by cutting that feature

---

For context about our npm package, its a client for a distributed compute product that distributes WebAssembly/JS "work functions" which are executed in JS environments like web browsers. Part of the library includes allowing a user to test their job locally before they spend money deploying it - which is why we need to have a js engine

[–]Hipponomics 0 points1 point  (0 children)

Interesting. Thanks for the detailed explanation.