06:30 <mattip> I think we need to be more feature complete before asking to be "official". The longer it takes us to get there, the more we look like vaporware

06:33 <LarstiQ> how far to get there?

07:10 <mattip> being able to run the numpy fork would be a big milestone

07:10 <mattip> being able to run the fork on GraalPy, PyPy, CPython

08:37 <antocuni> mattip: yes sure, I'm not proposing to write the PEP before the summit. I'm proposing to start the "we would like to write a PEP" conversation at the language summit

08:38 <antocuni> what about organizing a call next week to discuss what to present at the summit?

09:34 <mattip> +1

11:29 <Hodgestar> +1

11:31 <Hodgestar> We could also write a story on HPy for LWN. They cover quite a few Python topics and HPy is certainly relevant to a large section of their audience (even non-Python people are likely interested in the API design aspect). I'm not sure if we should write such an article right now, but soon.

11:39 <Hodgestar> One thing that confuses the discussion with CPython core is that HPy doesn't *need* anything from CPython core, in the sense that it's already designed to function without assistance from core. The question is then does CPython core want to support HPy in some way, and if so, in what way.

11:40 <Hodgestar> At one extreme CPython core adopts the CPython implementation of HPy and includes it in core. At the other, CPython just commits to talking to us on design and not breaking things (which I think Petr, Viktor and a few other already are).

11:41 <Hodgestar> So maybe it's more a question of "what is the correct next step for our relationship with core" and not so much "what do we need from core".

11:46 <cfbolz> agreed. I mean I think we definitely don't want to end up in a situation where the development of hpy is done under the python-dev umbrella and its rules

13:08 <Hodgestar> cfbolz: If HPy stays outside core for the moment, any idea how the technical integration should look? E.g. should we ask for new C API methods if that would help us? Or is there a tiny subset of HPy that could be implemented in CPython?

13:10 <Hodgestar> I guess another question for CPython is how do they deprecate the old C API? It's probably not a question for now, but I think it is a question for CPython core rather than HPy devs. I feel like Victor's work has been various attempts to start to answer this question.

13:12 <Hodgestar> Given that right now almost everyone has to recompile for every C Python release, it's not that impossible to imagine a biggish break with a compatibility C layer that goes away over time? Perhaps falls into the "nice to have but a lot of work" category.

14:18 <LarstiQ> As a user dealing with painful (old) numpy using C-API bits of code, that is what I want to see from CPython. A path to deprecating the C-API or at least strongly encouraging something like HPy over it.

14:27 <mattip> as long as CPython is written in C I do not see how they can deprecate the C-API,

14:27 <mattip> and I don't think there are new C-API functions needed by HPy

14:29 <mattip> the abi3 standard did not become popular, I am not sure why. Probably because cython doesn't support it well

14:30 <mattip> I think mainly what we want from CPython is a commitment not to create a competing opaque pointer standard

14:30 <mattip> but to get to that point we must prove HPy is viable

14:38 <antocuni> ideally, I'd arrive at the point in which HPy becomes the standard and default way to write and compile extensions

14:38 <antocuni> *I'd like to arrive

14:39 <antocuni> i.e., if you do "setup.py build" (or equivalent) you get an hpy extension by default, the docs show HPy examples, etc.

14:39 <antocuni> then if you really want to be CPython-specific, you can opt-in and use the cpython-specific API

14:42 <Hodgestar> antocuni: I like your very practical vision.

14:43 <antocuni> that's what I mean when I say that we need a commitment from the Python community as a whole

14:43 <Hodgestar> Maybe we are even close enough that we can write down the basic steps with some confidence and perhaps present & discuss those steps at the language summit.

14:43 <antocuni> even better, in the fullness of time I'd like to deprecate "#include <Python.h>", you should use "#inlcude <CPython.h>" instead

22:10 <mattip> +1