dev call 20220113

Dev Call: 13 January 2022

Antonio, Ronan, Matti, Simon, Tim, Florian, Stepan, Mohaned

Ronan considers the core data struct "Numpy array" to be done (except of tp_traverse).
The main problem right now in Numpy: there are dtypes that do not have homogeneous types (more likes structures). So, Python objects could be anywhere in the native memory chunk. This makes the deallocation complicated. The root problem then is that we cannot call HPy API functions from tp_traverse (it might be executed by the GC itself). We would need to know the position of the Python objects. Ongoing discussion on: https://github.com/hpyproject/hpy/issues/252#issuecomment-1013224066
Antonio suggested to put this information into a C-level list such that we don't need the HPy context. Let's open an issue for the tp_traverse problem.

Simon: The string format API should clearly be separated between dealing with C variables or Python objects. PyErr_Format is used a lot. But we should analyze how exactly it is used. Do they mix C variables a lot?
HPy is missing documentation about: can we memcpy a C-level array that contains HPyField? The answer is: In general, no! But doc doesn't say that.
We were discussing a lot about if we should introduce an API that allows the programmer to get an HPy context out of nowhere. Let's continue discussion on https://github.com/hpyproject/hpy/issues/268

Stepan: PR #276; introduced API for acquiring/releasing GIL
Stepan: PR #279; introduced HPySequence_Contains
Stepan: PR #281; added HPy_CLEAR macro
Stepan: looks into adding PyErr_Format
Stepan: looked at pybind11 but is not longer sure if that is useful.
Mohaned: Working on porting Matplotlib to HPy Also needs PyErr_Format for that. Main issues: most code base is implemented in C++. HPy has compiling issues.