<vstinner>
Hodgestar: i'm stuck with my PEP 620. people started to complain about my C API Py_TYPE() change which now disallow "Py_TYPE(obj) = type" (Py_SET_TYPE(obj, type) must now be used)
<vstinner>
i'm thinking about writing a shorter and less controversial PEP, but a narrower scope: avoid accessing directly C API structure members
<vstinner>
like add getter and setter functions: PyFrame_GetBack(), PyThreadState_GetInterpreter(), etc.
<vstinner>
*and* deny abusing macros like Py_TYPE(obj) = ...
<vstinner>
but such PEP would not make structures opaque, since it's a long term goal, and other changes should be fixed first
<vstinner>
PyFrame_GetBack() is really important. frame->f_back no longer works in Python 3.11
<Hodgestar>
vstinner: Ping.
<Hodgestar>
vstinner: Are you asking if I think that is a good idea?
<vstinner>
Hodgestar: months ago, we discussed the idea of writing a PEP to explain how the current C API is a problem by itself
<vstinner>
Hodgestar: such PEP doesn't exist yet, and months later, i still get exactly the same complains: "this change is counter productive and useless"
<vstinner>
Hodgestar: i'm thinking aloud on how to write down such PEP
<Hodgestar>
vstinner: I'm not a fan of writing informational PEPs that could just be a blog post or an email. We wrote the HPy manifesto, which we could still update and share more widely if needed.
<vstinner>
Hodgestar: where can i find the HPy manifesto?
<vstinner>
Hodgestar: do you think that my work on "fixing the C API" (like Py_TYPE() converted to a static inline function and adding PyFrame_GetBack() function) is useful for HPy?
<Hodgestar>
vstinner: I don't think it's *necessary* for HPy. People who are going to use HPy will still have to port their C extensions to it. Removing some things like "Py_TYPE(obj) = type" is something that will need to happen for HPy, but it's also not a big change to make, so I don't know whether for any particular project "small change now and big changes latter" is any better than "big changes later".
<Hodgestar>
vstinner: For me the biggest immediate win for CPython in enforcing calling a static function Py_SET_TYPE is that CPython could put something else inside that static function if it liked (I don't know what exactly one might do there, but it seems nice to be able to change what happens slightly rather than to not be able to change what happens without also going through a couple of years of rounds of deprecation).
<Hodgestar>
vstinner: In the end I guess it's up to the core CPython developers to decide whether they find that flexibility useful or not. I will agree that it is a very tiny amount of flexibility while PyObject and similary memory layouts are exposed elsewhere.
<vstinner>
Hodgestar: in my experience Python 3.8 => 3.9 was smoother than Python 2.7 => 3.0
<vstinner>
Hodgestar: my idea is to do the same for the C API
<vstinner>
Hodgestar: it's better to put "a few" "small" C API changes in each 3.x version, than breaking the C API completely at once
<vstinner>
Hodgestar: adapting numpy for Py_TYPE() took 5 lines. numpy is my example of "large C extension"
<Hodgestar>
vstinner: Agreed that these changes are nothing like the madness of 2.7 -> 3.0, so I wouldn't make that comparison.
<vstinner>
Hodgestar: rewriting an existing C extensions with HPy is like Python 2 => 3 for me
<Hodgestar>
vstinner: I guess HPy and your efforts are at sort of opposite ends of the "big" vs "lots of small" changes to address the same issue. I feel that you agree too that a big change has to happen at some point and that there is no way to reasonaby make PyObject and object life times without one?
<vstinner>
Hodgestar: my work cannot fix root issues which prevent to optimize CPython, yeah a deep rework of the C API is required
<vstinner>
Hodgestar: for example, for make PyObject, it must be excluded from all existing C structures. currently, it's always the first member of *all* C structures
<vstinner>
to make PyObject *opaque*
<vstinner>
well, it was propose to make PyObject empty, and add a new _PyObject allocated *before* PyObject* pointer, similar idea than PyGC_Head
<vstinner>
Hodgestar: another blocker is the stable ABI. changing PyObject *will* break abi3
<Hodgestar>
vstinner: I think part of the reason you are getting push back from CPython developers is exactly because the "big benefits" are not reachable solely with what you're proposing (and I think we all agree on that). So "we can get some smaller benefits" is a harder sell. I don't know what to do about that exactly (I also don't really have much of a say given that I'm not a Python committer).
ronan has quit [Ping timeout: 245 seconds]
ronan has joined #hpy
dalley has joined #hpy
marvin has quit [Remote host closed the connection]
marvin_ has joined #hpy
<antocuni>
I'm confused. We merged the gh actions branch, but it seems they are not run
<antocuni>
let's see what happens when we merge it
<Hodgestar>
antocuni: I think we need 'on: [push, pull_request]'. It was probably just a small oversight in the original gh PR that left out the 'push'.
<antocuni>
I seem to understand that [pull_request] runs the actions also after the merge. If so, that's what we need
<antocuni>
we never push directly to master anywa
<antocuni>
*anyway
<Hodgestar>
Well, let's see.
<Hodgestar>
Ah, someone already added the doc build to the gh actions. Thank you whoever did that!