45 comments

[ 3.0 ms ] story [ 108 ms ] thread
Does this work for packages like PyTorch too, in GPU mode?
Yes, it uses your native python installation so everything that works with python should work with this.

I have had success running sbert, faster-whisper and various other GPU accelerated packages.

A truly incredible feat of FFI!
Super cool! Fun, useful and slightly cursed indeed
This is really fun indeed, well done, I like it. It’s funny how you decided to demo it with a library that does lots of c++ bindings it’s self. Now someone can put a wrapper around this to hide the python imports, so we can claim JS is the only language we need.
So you can now shoot yourself in the foot with both Python and JavaScript package management?
The package targets deno. It can be imported directly without using any package manager.
So you can shoot just one foot with pip
maybe they will cancel each other ?
Hah, we wish. In practice what will happen is we'll get the black hole spacetime disruption due to NPM package weight combined with dependency hell from pip
Deno fixed the mess of JavaScript package management... But even NPM is light years ahead of Python. I have no idea why you'd want to inflict that on yourself once you've escaped it. I guess the only reason is there's some Python package that you have no option but to use.
Javascript's package management is so much better than Python's IMO...
Package management, sure. The packages themselves leave a lot to be desired in JS.
I believe that's the joke, the two package systems have orthogonal nightmares
I had missed this message but have to say I love the expression "orthogonal nightmares", really captures it well :)
Let Python from Deno write to SQLite, Deno serve a webpage that use JS to accessing «static» SQLite using HTTP range requests, and we have come full circle

(Joke, but would be a cool prototype)

Is there an equivalent for Node? I'm glad I haven't needed it since, but I couldn't find anything nearly so seamless when I last looked.
why can't you just exec a python shell command to do the same thing? i'm actually slightly puzzled that "FFI" is its own thing when every language has a way to exec shell commands
You can if you are just executing a static python script never changes.

But if you want to call some python functions with your TS input then you would need to serialize the TS input, pass it as an arg to the script, there deserialize it and then call the python function with the input. And if you wanted to call multiple python functions then your first arg to the python script would need to be the name of the function, only then the serialized data. Plus you would need to implement a switch case on the python side to execute the right function.

right. ok. thats not hard^? like at all? and in fact ive had multiple bugs that ultimately had to do with serialization being quietly abstracted over for me that if i had just handrolled it myself i probably wouldve been consciously aware of my bad choices.

^i know this is probably arrogance out of naivete, just teasing out what exactly i dont know that i dont know about what FFI does.

There are limits to what the commandline arguments can take. And even if you fallback to files instead, you still need to serialise a potentially huge amount of data. (Wanna serialise a 1GB tree that is going to get only one lookup in each call to the script?) On top of that, you're missing any chance of in-memory caching, because the script call can't preserve that, while FFI could. Then there are things that are just not possible to serialise like pointers to mapped memory, file descriptors (outside of unix sockets), etc.

Finally even if everything works, a command execution and parsing results is massively slower than a function call. So yeah, there's lots of restrictions on what you can practically do that way.

deno_python exposes Python modules to JavaScript in a way that makes it possible access the API of any Python module out of the box, as if it were a JS API. Executing a Python shell command is quite different.

Here, FFI is used to interface with the Python Interpreter C API. Argument for FFI against just executing shell commands is performance, efficiency, and that you can make calls from same process instead of spawning a subprocess. When doing [de]serialization over shell interface, a lot of things will be hit and miss. But for deno_python, type conversions are widely supported. You can even pass around objects by reference with zero copy, which would otherwise require copy over a shell interface.

The organization name "denosaurs" very roughly works for a combination of deno and python too: snakes fall into the clade of Lepidosaurs. Dinos are Archosaurs.

I wonder if there's another programming language featuring a reptile. What's this "Lizard" language Duckduckgo's telling me about?

I always get a kick out of well named projects - good eye!
Maybe not to the same degree, but Zig!

Its users are even called Ziguanas.

Can’t decide if I’m more amazed or terrified at the prospect of fighting both JS and Python package managers in the same process.
Deno package management is saner but more limited
Everyday we stray further from gods light.
Next step would be getting ObservableJS running and using it to write notebooks. (There is a vscode plugin for this that might be adapted.)
Is Deno really performing so badly that it has to get PIP'ed? I thought NodeJs would be first...
Not at all but if you have an api in js and you want to do any sort of machine learning, ai, forecasting well all the best tools are in python.

The you have two choices you rewrite your api into python or you call python from your js.

ngl this is a little cursed, but awesome
An alternative is metacall. The example in the readme is about calling Python from Javascript, but it also works with other languages, like Ruby, C#, Java, and other languages

https://github.com/metacall/core

List of supported languages here https://github.com/metacall/core/blob/develop/docs/README.md...

In the future, maybe webidl (or extensions of it) will bring interoperability between languages too. At the moment there is https://mozilla.github.io/uniffi-rs/ for interoperability between Rust and a number of languages (basically the ones mozilla needs: Swift, Kotlin, Javascript)

[flagged]
Even though this is a but cursed, it could allow more people to access Pythons large and exclusive ecosystem libraries!