<vstinner>
"Not rely on stable references or pointers for object identity": Python 3.10 adds Py_Is(), Py_IsNone(), Py_IsTrue(), Py_IsFalse() to the C API: https://docs.python.org/dev/c-api/structures.html#c.Py_Is
<vstinner>
"Not expose reference counting as part of the API: (...)
<vstinner>
It would be better to use an interface that allowed the caller of the API to explicitly communicate its own requirements via obj = Py_I_Need_A_New_Reference(...)"
<vstinner>
Python 3.10 adds Py_NewRef() to the C API
<vstinner>
Hodgestar: ^^ maybe you would like to update the wiki page to mention these new functions
<vstinner>
i sent it to python-dev, capi-sig and hpy-dev :-)
<Hodgestar>
vstinner: Woot. I sent some questions via email.
<vstinner>
Hodgestar: it's even lighter than your light manifesto
<vstinner>
Hodgestar: whenever possible, i tried to avoid technical details
<Hodgestar>
vstinner: Re Py_Is...() and Py_NewRef() -- the manifesto wasn't really intended to include details, but perhaps I can add them to the "What Changes are Needed and Why" document? Or perhaps mention them in some quick way in the manifesto? I will see what looks nice.
<vstinner>
Hodgestar: this PEP is like the 100th version of "C API PEP" I'm writing for 4 years :-D
<vstinner>
i'm not sure that my intent is obvious from the PEP :-/
<vstinner>
i would like to explain that (1) the C API has flaws (2) there are really good reasons which prevent to introduce any incompatible C API change
<Hodgestar>
vstinner: Maybe a different more practical question is -- what happens with such a PEP? Can be it "accepted"?
<vstinner>
Hodgestar: an informal PEP can be accepted
<vstinner>
Hodgestar: i would like to get an accepted PEP just to write down that: yes, the C API must change
<Hodgestar>
vstinner: That is useful. Does acceptance mean anything in particular? E.g. The SC agrees?
<Hodgestar>
I suppose we could also find a way for people to "sign" the manifesto. Might be useful.
<vstinner>
Hodgestar: i think that the obvious following PEP would be the least controversial changes for future C API additions like: avoid borrowed references
<vstinner>
honestly, "Not expose static types" would deserve its own PEP. there are many technical challenges for the backward compatibility if we remove &PyLong_Type
<vstinner>
"Expose constructs generally useful in C" is nice but it might be its own PEP as well
<vstinner>
"Provide an explicit execution context" is great for HPy, but i don't think that it's worth it for the existing C API
<vstinner>
"the ship has sailed" :-)
<mattip>
does debug/src/debug_ctx.c compile cleanly on windows?
<mattip>
it (and test_argparse.py) have __attribute__(),
<mattip>
and debug_ctx.c also has fprintf("... %ld ...") where it needs fprintf("... %Id ...") (replace lower case 'l' with upper case 'i')
<Hodgestar>
mattip: The hpy test suite (including debug) passes on CPython, and I *think* PyPy has its own debug_ctx code.
<Hodgestar>
mattip: E.g. the hpy __attribute__ in debug_ctx.c is wrapped in #ifndef _MSC_VER (at least in the version in the HPy repo).
<Hodgestar>
vstinner: My vote for changes to the existing C API would be to not take things anyway, because that will make life hard, and instead just add the "right way" for now where one can (e.g. like you did for Py_Is, etc).
<mattip>
it seems pypy 3.7 did not get the 0.0.3 code yet?
<mattip>
ahh, it hasn't been merged yet
<Hodgestar>
vstinner: Do you think there is any appetite withing the SC / Python committers to "adopt" the HPy approach? I.e. to bless the idea of "we would like this to happen outside of Python but we'd like to help / work with it?" There seemed to be a lot of interest at the language summit? Maybe we just need to recruit more?
<Hodgestar>
mattip: Yay -- at least the solution is fairly simple.