That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
You don't need to modify the code, just add a wrapper.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful.
The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
You don't need to modify the code, just add a wrapper.
Still not the same.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.
Comments
Nim has an automated generator for C/C++ wrappers or translating from C.
Also there are very easy ways to create Python modules in Nim:
https://robert-mcdermott.gitlab.io/posts/speeding-up-python-...
https://github.com/yglukhov/nimpy
Thanks for the links.
That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
You don't need to modify the code, just add a wrapper.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
Still not the same.
Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.