08:00 <fangerer> Good morning! We will have our HPy dev call in 1 h.

08:59 <antocuni> good morning! I'll be 2 minutes late, but I'm coming

10:41 <steve_s> Module state issue: https://github.com/hpyproject/hpy/issues/286. Thinking about it again, I think that what Antonio suggested: do ideal API, accept that it's a tiny bit broken on current CPython implementation, could be an acceptable way forward that allows to have the right API from the start...

11:03 <steve_s> One thing we, I think, never discussed: maybe we should try HPy with current CPython subinterpreters to verify the assumption that HPy indeed can support subinterpreters. Can be a nice student project maybe.

11:28 <fangerer> thank you for the issue

11:28 <fangerer> yes, we should try HPy with multiple subinterpreters

12:17 <fangerer> Hodgestar: btw. this is the paragraph I was referring to when I tried to explain why tp_call is bad when calling types (see https://peps.python.org/pep-0590/):

12:17 <fangerer> Another source of inefficiency in the tp_call convention is that it has one function pointer per class, rather than per object. This is inefficient for calls to classes as several intermediate objects need to be created. For a class cls, at least one intermediate object is created for each call in the sequence type.__call__, cls.__new__, cls.__init__.

12:40 <fangerer> today's dev call minutes are up: https://github.com/hpyproject/hpy/wiki/dev-call-20230112

12:41 <Hodgestar> Hmm. I read that paragraph before but I have no idea what case it is talking about. How are cls.__new__ and cls.__init__ involved at all in calling an object? And if the object is itself a class where "MyCls()" has been overridden by tp_call somehow, I still don't know why __new__ or __init__ would be involved. Probablyy I am missing something? Do you know some Python code which would trigger the case the paragraph refers to?

12:41 <Hodgestar> Thank you for doing the minutes again!

15:15 <Hodgestar> fangerer: I see https://peps.python.org/pep-0590/#using-the-vectorcall-protocol-for-classes has similar text, so this is somehow related to "cls(xxx)". It looks like in CPython "type" has a tp_vectorcall but probably I have to read the code to understand why this is all such an issue.

15:37 <mattip> calling cls(xxx) will end up calling cls.__new__ and cls.__init__, right?

15:56 <Hodgestar> Yes, but what do those calls have to do with tp_vectorcall?

16:22 <mattip> it gets rid of some of the boxing/unboxing of arguments in the calls, which need to allocate a tuple

16:42 <steve_s> hm, actually, I guess that also falls into the box of "we cannot not change signature of existing slots on CPython". Still, they could have reused the legacy slot that's used for vectorcall offset (tp_print I think it was) for the function itself, but they chose to put that function into the objects instead. Why?