pybind11 VS py2many

I'm investigating using C++ to build a REST server, and would love to know of people's experiences with Crow-- or whether they would recommend something else as a "medium-level" abstraction C++ web server. As background, I started off experimenting with Python/FastAPI, which is great, but there is too much friction to translate from pybind11-exported C++ objects to the format that FastAPI expects, and, of course, there are inherent performance limitations using Python, which could impact scaling up if the project were to be successful.

I have a C++ function computing a large tensor which I would like to return to Python as a NumPy array via pybind11.

This is based on the Google Ink Stroke Modeler C++ library, and using pybind11 to make it available on python.

pybind11 makes it easy to call C++ from Python if you want to mix.

If you've never used Pybind before these pybind tests[1] and this repo[2] have good examples you can crib to get started (in addition to the docs). Once you handle passing/returning/creating the main data types (list, tuple, dict, set, numpy array) the first time, then it's mostly smooth sailing.

Pybind offers a lot of functionality, but core "good parts" I've found useful are (a) use a numpy array in Python and pass it to a C++ method to work on, (b) pass your python data structure to pybind and then do work on it in C++ (some copy overhead), and (c) Make a class/struct in C++ and expose it to Python (so no copying overhead and you can create nice cache-aware structs, etc.).

[1] https://github.com/pybind/pybind11/blob/master/tests/test_py...

I have a python module for which the logic is written in C++ and I use pybind11 to expose the objects and functions to Python.

Reading from Python requires a wrapper, using pybind11 this is fairly done.

Also I can highly recommend starting using C++ to augment your Python code, i.e. find the parts that are slow or undoable in Python and write those in C++ then expose them as Python functions. You can use https://github.com/pybind/pybind11 to call C++ code from Python.

> Another problem is that there are hundreds of built-in library functions that need to be compiled from Python from C

An approach I've advocated as one of the main authors of py2many is that all of the python builtin functions be written in a subset of python[1] and then compiled into native code. This has the benefit of avoiding GIL, problems with C-API among other things.

Do checkout the examples here[2] which work out of the box for many of the 8-9 supported backends.

[1] https://github.com/py2many/py2many/blob/main/doc/langspec.md

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Reimplement a large enough, commonly used subset of python stdlib using this dialect and we may be in the business of writing cross platform apps (perhaps start with android and Ubuntu/Gnome)

For py2many, there is an informal specification here:

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Would be great if all the authors of "python-like" languages get together and come up with a couple of specs.

I say a couple, because there are ones that support the python runtime (such as cython) and the ones which don't (like py2many).

It'd not fully solve your issue, but have you ever seen https://github.com/py2many/py2many ?

Cython doesn't consume python3 type hints and needs special type hints of its own. But it's certainly more mature than other players in the field.

What we need is a rpython suitable for app programming and a stdlib written in that dialect.

https://github.com/py2many/py2many/blob/main/doc/langspec.md

No intermediate AST. To understand the various stages of transpilation and separation of language specific and independent rewriters, this file is a good starting point:

https://github.com/adsharma/py2many/blob/main/py2many/cli.py...

Link to the test that's relevant for this discussion:

https://github.com/adsharma/py2many/blob/main/tests/cases/in...

This is an explicit deviation from python's bigint, which doesn't map very well to systemsey languages. The next logical step is to build on this to have dependent and refinement types.

Work in progress here:

https://github.com/adsharma/Typpete