06:46 <mattip> the pypy rpython-level debug handle manager hangs on to a universal handle manager

06:47 <mattip> is that an internal detail or a design feature: i.e. is it expected that users can mix debug and universal mode in the same process?

08:14 <Hodgestar> It's expected that one can turn on the debugging context per-module.

08:44 <mattip> ok, thanks. I think the key is that the tests need to set a set_on_invalid_handle callback to avoid the fatal error

08:45 <mattip> btw, Christian Helmes asked about abi3 and universal mode in a cpython discussion thread

08:45 <mattip> https://discuss.python.org/t/lets-get-rid-of-the-stable-abi-but-keep-the-limited-api/18458/14

08:46 <mattip> I think the answer is that "universal mode is different than abi3, and allows turning on a debug mode at runtime"

08:46 <mattip> and then a link to docs

08:47 <mattip> which would be here if this PR were already live

08:47 <mattip> https://github.com/hpyproject/hpyproject.org/pull/28/files#diff-02cc34efba96d3510436acbd9b57802395c87cd569ef9a3c640eac139bd4e9d6R25

08:59 <phlebas> mattip: what's keeping us from merging that PR?

08:59 <mattip> I just pushed the last commit a few minutes ago, review would seem prudent

08:59 <phlebas> ah, sorry, I thought that was the old PR that stepan had opened, i now clicked and saw it's yours

09:04 <phlebas> mattip: thanks for doing this!

10:58 <phlebas> any thoughts we should share https://github.com/markshannon/New-C-API-for-Python/issues/6 - " Should we pass the interpreter as an explicit parameter?"

10:58 <phlebas> I keep thinking about our stack allocation discussion, but nothing else comes to mind as to why it is an explicit argument

13:20 <Hodgestar> "Explicit is better than implicit"? ;)

13:20 <Hodgestar> If one cares about performance at the level of an extra argument on the C stack, don't call the Python API?

13:27 <Hodgestar> I posted some things about where HPy is to https://github.com/markshannon/New-C-API-for-Python/issues/8

13:29 <Hodgestar> Where by "don't call the Python API" I mean "don't call the Python API all over the place and deep in the call stack". Have C code work with things you give that don't require the context.

15:50 <Hodgestar> I think HPy devs and the CPython devs are talking past each other somewhat in Mark's repo, because the CPython devs want to redevelop the C API for the core of CPython, while HPy is focussed on the API for extension development.

15:52 <cfbolz> yeah, I agree with that. I think there are really two different ways to use the C API

16:06 <phlebas> mark actually raises a good question that makes that different line of thinking clear to me here: https://github.com/markshannon/New-C-API-for-Python/issues/6#issuecomment-1227343014

16:08 <phlebas> maybe the "real" goal should be that if the API/ABI for Python is broken, they should really move to a world where the internal C API is really just unstable and version specific, and the external API is something else (like HPy)? and then the choice of the extensions is to compile in "CPython mode" oder "Universal mode" (or even "PyPy mode", "GraalPy mode", "Rust mode", if any of those should make sense and the relevant impls provide it)

16:09 <phlebas> which is kind of how we approached hpy, but maybe not how mark is approaching this right now? i am not sure I can infer that from reading the issues on the repo or the current discourse discussion

19:00 <Hodgestar> My assumption is that Mark's immediate need is to break some parts of the C API for performance gains, but that is really just a guess. And on that front I think we all agree / already knew that the current C API hampers performance for implementations other than *past* CPythons.

19:03 <cfbolz> yes

19:03 <cfbolz> but the strategy of saying "let's break the API once, in exactly the right way so that now current CPython is faster" is not very sustainable

19:05 <Hodgestar> Agreed.