search

hpyproject / hpy

HPy: a better API for Python
https://hpyproject.org
MIT License
1.02k stars 52 forks source link

Support object members #347

Closed timfel closed 2 years ago

timfel commented 2 years ago

We already define HPyMember_OBJECT, but using it in

HPyDef_MEMBER(Foo_OBJECT_member, "OBJECT_member", HPyMember_OBJECT, offsetof(FooObject, OBJECT_member))

fails in universal mode, as the included test demonstrates, since the embedded member must an HPyField in this mode. This should work, since it's annoying to have to define getters/setters manually here.

hodgestar commented 2 years ago

What happens during porting a C extension? Presumably initially the member is a PyObject *. Will compilation in universal mode then fail? And once the member is been made an HPyField, will compilation work in both CPython and universal mode?

I am wondering whether we need a legacy_defines or similar? Or at least some way to make it clear "these object members should use HPyField and those should use PyObject*".

timfel commented 2 years ago

What happens during porting a C extension? Presumably initially the member is a PyObject *. Will compilation in universal mode then fail? And once the member is been made an HPyField, will compilation work in both CPython and universal mode?

As long as it is a PyObject, compilation in universal mode just fails. After it is an HPyField, it works in both CPython C ABI mode and HPy universal mode. It even works to have an HPyField and still use the legacy definition for members, since then you have to compile in C ABI mode and the HPyField is binary equivalent to PyObject in that mode. So afaics, nothing can go wrong even if you just partially port.