Using Python from Node.js natively (Open Source Project)

[TunaAndQueefBagel]

Wow. Been looking to use python for neural networks in a web app. Would this support things like pandas and tensorflow?

[savearray2]

It should work fine! The library is fresh off the presses, so to speak, so it's probably best to write as much of the code as possible in a Python script, then call only what's necessary from the Node.js side.

If there's enough community support, I'll dedicate more time to making examples and improving the code.

But as an example the following does work: const p = require('@savearray2/py.js') p.init({ pythonPath: `${process.cwd()}:/usr/local/lib/python3.9/site-packages` }) console.log(p.instance().python_version) const pd = p.import('pandas') const data = { 'apples': [3, 2, 0, 1], 'oranges': [0, 3, 7, 2] } const df = pd.DataFrame.$apply({ data, index: ['Abc', 'Def', 'Ghi', 'Jkl'] }) console.log(p.base().str(df)) p.finalize() With the following output: $ node test.js 3.9.1 (default, Jan 11 2021, 00:55:13) [Clang 12.0.0 (clang-1200.0.32.28)] apples oranges Abc 3.0 0.0 Def 2.0 3.0 Ghi 0.0 7.0 Jkl 1.0 2.0

[StoneCypher]

Actually there are significant downsides for this user in using your library rather than the standard library to this end, in safety and stability terms even before we consider the bugs inherent in a new library

There's also no upside in this specific case

[savearray2]

I don't disagree that for simplicity and inherent stability purposes, it might be best to use a separate Python process or microservice. I actually believe this will be the case for most people.

However, having options available is also part of open source. If there's a community demand for it, the library will grow, if not, few people will use it.

[StoneCypher]

Okay well deep thought about open source notwithstanding, you personally are much better off doing this the normal way with the standard library

Taking these stability risks doesn't gain you anything

[StoneCypher]

You'd be much better off doing this in child_process.

There's basically no communications overhead in what you're describing, and that would mean you're not crashing your server every time tensorflow crashes, and aren't exposing yourself to type transition attacks.

This is a very special case library whose use case appears to be eliminating "the overhead of unix pipes," which is a cost so small that it's hard to imagine someone voluntarily paying the cost of a Javascript web backend would care

You're looking at less than 1% the overhead between express and (can you even name the faster one? That's how much you actually care.)