I'm Barry Scott and the maintainer of the PyCXX C++ interface for Python.
In principle it would appear that implementing the PyCXX C++ API in terms of handles would be a natural fit. I should be able to be source compatible with existing PyCXX projects.
Example module: https://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Demo/Python3/simple.c... Docs for Python: 3 http://cxx.sourceforge.net/PyCXX-Python3.html Source code: https://sourceforge.net/projects/cxx/
Barry
Hello Barry, I had a quick look to the example module you linked to: it seems that basically, PyCXX gives the programmer a C++ syntax to use Python objects, but without exposing the API calls directly, doesn't it? If this is correct then yes, I think that in principle it should be possible to write a different "backend" which implements PyCXX in terms of HPy instead of the current Python/C: without touching the user code at all. Are there many extensions based on PyCXX around? Is there anything that you need from our side and/or some design decision which could make your life easier/harder/impossible?
ciao, anto
On Wed, Jun 3, 2020 at 7:53 PM Barry Scott <barry@barrys-emacs.org> wrote:
Yes that the design goal.
There are ways to get the PyObject * out and push it in for the cases that PyCXX does not cover.
But the goal is that that should be necessary.
If this is correct then yes, I think that in principle it should be possible to write a different "backend" which implements PyCXX in terms of HPy instead of the current Python/C: without touching the user code at all. Are there many extensions based on PyCXX around?
Yes a new backend using HPy was what I immediately thought about. Handle allocate/deallocate maps on to C++ c'tor/d'tor nicely.
PyCXX is 20 years old, mature and stable which means for a lot of users it just works so I do not see much in the way of user communications.
As for the number of extensions I'm not sure of the size of the user base. I see 1,000 downloads a month. Its packaged for debian and fedora (which will not be in the download stats).
Is there anything that you need from our side and/or some design decision which could make your life easier/harder/impossible?
Just as you have been doing I ended up with a lot of #define macros to code generate trampolines and struct array entries.
If I read the HPy code right you have a module with module level functions at the moment and not much more. I think I will need HPy to add more API coverage then can start on the HPy backend, like support for classes.
Barry
On Tue, Jun 9, 2020 at 6:25 PM Barry Scott <barry@barrys-emacs.org> wrote:
cool. Note that HPy also provides methods to convert between HPy handles and PyObject*, so it is probably possible to support this use case as well.
If this is correct then yes, I think that in principle it should be
+1
Support for writing types in C has been merged recently, and there is a PR which will be merged soon to extend the functionality: https://github.com/pyhandle/hpy/pull/42
Here is a simple example module, which also defines a type: https://github.com/pyhandle/hpy/blob/feature/hpymeth-refactor/proof-of-conce... Note that the new API is based on HPyDef; each HPyDef can be an HPyMeth, and HPySlot and eventually also HPyMember or HPyGetSet. There are macros to automatically generate the trampolines and fill the HPyDef definition, but the idea is that people will be free to avoid the macros and fill them manually, if they want. So probably for PyCXX you will want a slightly different set of macros/templates/whatever which produce the same result as HPyDef_METH&co.
ciao, Anto
Hello Barry, I had a quick look to the example module you linked to: it seems that basically, PyCXX gives the programmer a C++ syntax to use Python objects, but without exposing the API calls directly, doesn't it? If this is correct then yes, I think that in principle it should be possible to write a different "backend" which implements PyCXX in terms of HPy instead of the current Python/C: without touching the user code at all. Are there many extensions based on PyCXX around? Is there anything that you need from our side and/or some design decision which could make your life easier/harder/impossible?
ciao, anto
On Wed, Jun 3, 2020 at 7:53 PM Barry Scott <barry@barrys-emacs.org> wrote:
Yes that the design goal.
There are ways to get the PyObject * out and push it in for the cases that PyCXX does not cover.
But the goal is that that should be necessary.
If this is correct then yes, I think that in principle it should be possible to write a different "backend" which implements PyCXX in terms of HPy instead of the current Python/C: without touching the user code at all. Are there many extensions based on PyCXX around?
Yes a new backend using HPy was what I immediately thought about. Handle allocate/deallocate maps on to C++ c'tor/d'tor nicely.
PyCXX is 20 years old, mature and stable which means for a lot of users it just works so I do not see much in the way of user communications.
As for the number of extensions I'm not sure of the size of the user base. I see 1,000 downloads a month. Its packaged for debian and fedora (which will not be in the download stats).
Is there anything that you need from our side and/or some design decision which could make your life easier/harder/impossible?
Just as you have been doing I ended up with a lot of #define macros to code generate trampolines and struct array entries.
If I read the HPy code right you have a module with module level functions at the moment and not much more. I think I will need HPy to add more API coverage then can start on the HPy backend, like support for classes.
Barry
On Tue, Jun 9, 2020 at 6:25 PM Barry Scott <barry@barrys-emacs.org> wrote:
cool. Note that HPy also provides methods to convert between HPy handles and PyObject*, so it is probably possible to support this use case as well.
If this is correct then yes, I think that in principle it should be
+1
Support for writing types in C has been merged recently, and there is a PR which will be merged soon to extend the functionality: https://github.com/pyhandle/hpy/pull/42
Here is a simple example module, which also defines a type: https://github.com/pyhandle/hpy/blob/feature/hpymeth-refactor/proof-of-conce... Note that the new API is based on HPyDef; each HPyDef can be an HPyMeth, and HPySlot and eventually also HPyMember or HPyGetSet. There are macros to automatically generate the trampolines and fill the HPyDef definition, but the idea is that people will be free to avoid the macros and fill them manually, if they want. So probably for PyCXX you will want a slightly different set of macros/templates/whatever which produce the same result as HPyDef_METH&co.
ciao, Anto
participants (2)
-
Antonio Cuni -
Barry Scott