pybind11 VS py2many

And how to do this in the best modern way instead of dealing with Pythons native and annoying 30 year old C API: https://github.com/pybind/pybind11

Lots of asio on the C++ side, and lots of asyncio on the python side. Also pybind11 is just plain awesome.

Just use https://github.com/pybind/pybind11 . Your life will be a lot simpler that way.

Some work on the C++ side will be required. There's https://github.com/pybind/pybind11 for example.

Also if you need to write libraries for Python in C++: https://github.com/pybind/pybind11

You should also be aware of pybind11, which makes calling c++ code from python (or vice-versa) a fairly straightforward task, if this becomes necessary or convenient.

Pybind11 is what you are looking for.

pybind11

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...

This is awesome! The direction of using a subset of python, while leveraging the user base and static typing to accomplish some other everyday task in a different language is very legit IMO.

I took a cursory look at:

https://github.com/zanellia/prometeo/blob/master/prometeo/cg...

It seems quite similar in spirit to

https://github.com/adsharma/py2many/blob/main/pyrs/transpile...

I'm not spending much time on py2many last few months (started a new job). Let me know if any of it sounds useful - especially the ability to transpile to 7-8 languages including Julia, C++ and Rust.

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

If you stick to this subset of python

https://github.com/adsharma/py2many/blob/main/doc/langspec.m...

The tool can convert your code to C++/Rust/Go and give you a native binary which like you observe will run faster without the python runtime.

There are many open tasks that could use help.

It seems to be fully statically typed, for starters:

https://github.com/adsharma/py2many/blob/main/doc/langspec.m...

But, given LuaJIT and V8, it's obviously possible to generate high-performance code without such restrictions.

As for PyPy adoption, it's hindered more by the lack of API compatibility with CPython native extensions.

Renaming the language in the future is still a possibility. For now, all the tests here:

https://github.com/adsharma/py2many/tree/main/tests/cases

are run with cpython interpreter and verified for compatibility.

Even when there is a desire to innovate (design by contract or pattern matching as an expression), hope to do so without breaking cpython (as long as you stick to the subset).

I thought SMT2 (what you can feed to z3 -smt2), is a s-expression language that is the lowest level ("bytecode") thing. If you look at Dafny/Boogie, boogie is a much more human readable IR. I'm trying to build a pythonic variant of Boogie.

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

I'm interested in similar proposals that can provide the basis of some common syntax that could be transpiled to other functional programming languages https://github.com/adsharma/py2many

I'm less interested in the syntax (will take anything accepted by a modified ast module), more in the semantics.

Here's a syntax I played with in the past:

  def area(s: Shape):