Elixir string representation

Elixir strings are binary data.

"a" is not different than <<65>>.

So erlport can’t know if you want a u"" string or a b"" string (erlport doesn’t even know there is a difference on the python side).

You have to decide on your own on the receiving script which one you need.

So it boils down to writing your own python wrappers for everything you are going to use from third party libraries?

Yes.

This is how it always works, everywhere.

When you use some sort of FFI, you will always also write wrappers that do type conversion, or mapping at least.

But isn’t Erlport supposed to be the integration library here? It seems like it should automatically transform Elixir’s UTF8 encoded binaries into Python unicode strings?

Erlport is just mapping erlang terms to their most straight forward target representation. As an erlang library its not necessarily aware of elixir strings. And even if it were, how should it decide whether you want to receive "a" or b"a" on the other end?

Additionally it could be expensive if the library had to go through every binary sent from Elixir to check if it’s a valid UTF-8 encoded string and then convert it to Python string (and what if some binary data looks like a valid UTF-8 string accidentally?).

You are right of course, I don’t know what I was thinking with an erlang library.