You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Python API is particularly unstable, and it is planned that the SWIGged API will be replaced by a pybind11 version with more Pythonic names and more complete functionality.
Any indication on when this might become available?
When I wrote that three years ago, we had moved from swig to clif internally at Google. I assumed we would eventually release the clif bindings, or maybe the generated pybind11 bindings.
Now clif is unmaintained, and nanobind seems to be the new pybind11, so I'm not sure what to do.
Thanks. Is there a good way to avoid maintaining both clif bindings and pybind11/nanobind ones? Is the clif output close to usable as a starting point for pybind11 bindings?
Thanks. Is there a good way to avoid maintaining both clif bindings and pybind11/nanobind ones? Is the clif output close to usable as a starting point for pybind11 bindings?
I don't think so, but I don't know what the current state is of clif inside Google (I switched companies).
These days, I'd probably just ask my favorite LLM to convert the clif bindings to pybind11 or nanobind. I expect it'll probably do a reasonable job that can be finished with a small amount of manual fix-ups.
Maybe you can help it by giving the LLM the output of help(yourmodule), so that it can "see" the built bindings.
We happen to use pybind11 at my current company (Aurora Innovation) and it works well for us! I'd be happy with any of those options though. I was mainly curious to understand if I should be avoiding the current Python SWIG wrappers because some new/better Python API is forthcoming.
BTW, I'd be open to contributing a PR for the pybind option if that helps. I'm less familiar with the other Python binding libraries but could give any of those a shot if they are preferred.
BTW, former Googler here. I worked on Google Maps from 2005 to 2013! Jesse you're name looks really familiar although I don't recall if we crossed paths!
Hi there, I'm working with my open source team to get the contributor agreement signed. But in the meantime, hoping to get some feedback to see if I'm on the right track here: #524
We're getting close to feature parity on the SWIG bindings, and I'm thinking we'll want to publish the new library as a new major version of that s2geometry package.
We're getting close to feature parity on the SWIG bindings, and I'm thinking we'll want to publish the new library as a new major version of that s2geometry package.
It doesn't look like we're that close, but getting there. We should have a compat layer to avoid breaking everyone.
Activity
jmr commentedon Jan 6, 2026
Hello!
When I wrote that three years ago, we had moved from swig to clif internally at Google. I assumed we would eventually release the clif bindings, or maybe the generated pybind11 bindings.
Now clif is unmaintained, and nanobind seems to be the new pybind11, so I'm not sure what to do.
Do you have a suggestion? Or maybe @rwgk?
rwgk commentedon Jan 6, 2026
Roughly:
jmr commentedon Jan 6, 2026
Thanks. Is there a good way to avoid maintaining both clif bindings and pybind11/nanobind ones? Is the clif output close to usable as a starting point for pybind11 bindings?
rwgk commentedon Jan 6, 2026
I don't think so, but I don't know what the current state is of clif inside Google (I switched companies).
These days, I'd probably just ask my favorite LLM to convert the clif bindings to pybind11 or nanobind. I expect it'll probably do a reasonable job that can be finished with a small amount of manual fix-ups.
Maybe you can help it by giving the LLM the output of
help(yourmodule), so that it can "see" the built bindings.deustis commentedon Jan 6, 2026
We happen to use pybind11 at my current company (Aurora Innovation) and it works well for us! I'd be happy with any of those options though. I was mainly curious to understand if I should be avoiding the current Python SWIG wrappers because some new/better Python API is forthcoming.
deustis commentedon Jan 7, 2026
BTW, I'd be open to contributing a PR for the pybind option if that helps. I'm less familiar with the other Python binding libraries but could give any of those a shot if they are preferred.
BTW, former Googler here. I worked on Google Maps from 2005 to 2013! Jesse you're name looks really familiar although I don't recall if we crossed paths!
jmr commentedon Jan 7, 2026
Yes, that would be great.
I recognize your name from maps and speech.
deustis commentedon Jan 8, 2026
Hi there, I'm working with my open source team to get the contributor agreement signed. But in the meantime, hoping to get some feedback to see if I'm on the right track here:
#524
[-]Pybind wrapper for s2[/-][+]pybind11 wrapper[/+]pybind: Add S2Point bindings (google#524)
pybind: Add S2Point bindings (#524)
pybind: Add R2 bindings (#546)
deustis commentedon Apr 24, 2026
@jmr, are you in touch with the maintainer of the current PyPI
s2geometrypackage?:https://pypi.org/project/s2geometry/
The maintainer is listed as @figroc:
https://github.com/figroc
We're getting close to feature parity on the SWIG bindings, and I'm thinking we'll want to publish the new library as a new major version of that
s2geometrypackage.figroc commentedon Apr 25, 2026
@deustis I've added this repo as a Trusted Publisher in #406.
jmr commentedon Apr 27, 2026
It doesn't look like we're that close, but getting there. We should have a compat layer to avoid breaking everyone.
#583
I would also also give the new code some bake time before making a release.
pybind: Add S2LatLng bindings (#581)