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?
Reminds me of PythonMonkey, which provides really high level bindings to SpiderMonkey in Python. It ships as both a pip package and a standalone js runtime, the latter of which is very similar to this project!
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
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)
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
Not so much you can use inspect [0] to see a whole lot of information. I used this at work to auto generate json scheme of passed functions for openAI function feature [1]
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.
You can also do this in Nim, which basically means you can write any program you could in Python with libraries in Nim. https://github.com/yglukhov/nimpy
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
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.
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 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.
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
I wonder if there's another programming language featuring a reptile. What's this "Lizard" language Duckduckgo's telling me about?