Welcome to clif Discussions!

[rwgk]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[moloned]

What is the new direction ... care to elaborate?

boost::python isn't bad as long as you don't stray outside the lines and try to wrap custom data-types

Something that makes it easier to automatically generate wrappers for arbitrary types would be great

[rwgk]

Currently our general recommendation is to prefer https://github.com/pybind/pybind11 for Google-external use.

Internally, we’re actively working on changing PyCLIF to generate pybind11 code (instead of directly targeting the Python C API), which will make PyCLIF and pybind11 bindings fully compatible, so you can mix and match.

For the foreseeable future, external use of PyCLIF isn’t officially supported, although we’re happy if volunteers help keeping this OSS repo fresh (the current situation). Probably the pybind11-related developments will show up here, but no promises at this point.

Something that makes it easier to automatically generate wrappers for arbitrary types

That’s not a direction we plan to take with PyCLIF, but there are other efforts you might find interesting:

• https://pybind11.readthedocs.io/en/latest/compiling.html#generating-binding-code-automatically
• pydrake: Enable automated binding generation RobotLocomotion/drake#7889

In the future, any pybind11-based auto-generator solution should be compatible with PyCLIF.

PyCLIF is all about explicitly describing a C++ API to be wrapped via a simple "What You See Is What You Get" interface file (with a syntax derived from https://github.com/google/pytypedecl, which predates PEP-484).