After months of internal use without problems, we're ready to release cara for others to use. We would be very happy if others picked up cara and made it work for them. If you've been looking at the Cap'n Proto project but were hesitant to shoehorn it into your Python project, look no further!

Here's why you should use cara over pycapnp:

• Python dicts, lists, etc are used instead of thinly-wrapped C++ objects.
• Allows using multiple RPC backends as well as multiple serialization backends.
  • The existing backend (pseud/Tornado) has been tested internally and supports Level 0 and half of Level 1 of the [capnproto RPC specification][spec]. Promise pipelining wasn't worth it for our needs, but it's possible to add if you like.
  • If someone wants the capnproto serialization format, that's very possible with cara. The only thing you can't get is the 100% zero-copy format since Python objects don't have their memory laid out like that. It is possible to get zero-copy for any strings, as those are immutable in Python, and they're the biggest cost of copying anyway.

In the interest of being fair, here's why you should use pycapnp over cara:

• You're using capnproto objects as a zero-copy serialization format to call C++ methods (or be called by C++).
• You want something more stable (at least for now) since pycapnp is used in more places.
• You want these features now but don't want to implement them in cara:
  • Promise pipelining
  • capnproto serialization format for interoperability with other implementations

Clearly, for us, the ability to use more Pythonic structures and existing, proven, IO loops and more featureful RPC backends won over the actual zero-copy ability of Cap'n Proto (it's Python, how much performance are you really expecting?). Hopefully, the same is true for you and you want to use cara, too.

If you do, cara is open sourced under the Apache 2.0 license on GitHub.