-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nanobind port #9
Comments
How similar are the nanobind If not, to not develop a severe case of copy-pasteritis, we'd need to factor out the guts of the type conversions into core from-python and to-python functions, then hook them into the |
Interesting perspective. AFAICT, they're identical, except for changing the namespace. But of course there could easily be some odd corners where they differ (in particular, the removal of the holder concept when dealing with smart pointers). I suppose there's only one way to find out - I will attempt a copy paste and see what happens to the tests. Re: inheritance - would that not introduce a dependency on pybind11 as well as nanobind? This can easily increase binary size. |
I don't think there is a connection between
Duplicating all casters & then having to maintain everything twice is far worse. Of course divergence will appear ~immediately, creating a whack-a-mole game. (The "far worse" aspect is probably not very obvious for a single project in isolation, but I'm working with a gigantic codebase in a mono repo, it's very clear then how much human time is lost when something is copy-pasted like nanobind was.)
Another ~easy solution is to factor our generic casters and inherit in the |
My 2 cents, Google Benchmark seems to use nanobind... |
Nanobind looks fairly stable at this point. I recently got nanobind to work with my various Bazel projects and considering doing a port.
Are there any plans to release a
nanobind_abseil
? If not, I'm happy to take a stab at it in my spare time.The text was updated successfully, but these errors were encountered: