python bindings!

[markjm]

Hi - thanks for the great project!

I wonder if yall would be willing to see a contribution adding python bindings to this project? Seems like a great win to be able to get this tool running there. pyicu is great, but the building from source can be a pain, so being able to build and distribute wheels from this project seems like it might solve that pain point.

I have done some digging and see that diplomat already supports creating python bindings, so I dont suspect this would be a major lift.

Thanks!

[Manishearth]

Hmm.

So generally ICU4X wants to have Python bindings. We've not added them so far for two reasons:

Firstly, we'd prefer to have a pure python Diplomat backend without nanobind (rust-diplomat/diplomat#1102). That preference may not be well-motivated, but we're not sure. This is a lot of work and we haven't had time to do that.

Secondly, we'd probably have to help maintain the Diplomatbackend. @tyler-zeromatter is doing a great job of maintaining nanobind, but it's likely ICU4X will need some features that they haven't needed yet. That's fine, it's just work to commit to. We had a similar story with the Kotlin backend: it was contributed by a third party, and then improved upon by Android (and used in production), but the production-quality Android backend needed a fair amount of work to be usable by ICU4X for all the APIs we want.

Overall for each of the Diplomat backends used I am quite familiar with the backend code, and many of them have been written by other ICU4X team members. I wasn't familiar with the Kotlin code, but I am now. I'm less familiar with nanobind and this would be another thing for me (or some other ICU4X team member) to need to ramp up on and commit to maintaining.

Doing this as experimental bindings, the way we do for Kotlin, seems like a good start. Especially if we can find issues like rust-diplomat/diplomat#1100 in the process. And I'm definitely happy to accept patches to ffi/capi to tweak things for nanobind if necessary (e.g. I would be totally on board with resolving rust-diplomat/diplomat#1100 by just "disable those overloads for nanobind").

With an experimental backend, the idea is that we're not committing to stability, and we're not committing to all of the APIs being available, but we're leaving it available for people to use.

If stuff goes smoothly, we can consider graduating it to a "stable" bindings

So yeah, please experiment away, and feel free to make PRs here.

but the building from source can be a pain, so being able to build and distribute wheels from this project seems like it might solve that pain point

won't that be a problem here as well? Especially with the nanobind backend requiring a C++ setup. I encourage investigation here!