<fangerer>
Good morning. Hodgestar: yes, I think so too. Stepan is already experimenting a bit with `HPy_BuildValue`.
<fangerer>
For `HPyErr_Format` we could just have `HPyUnicode_FromFormat` and add a user function like `_HPy_New` that does calls to `HPyUnicode_FromFormat` and `HPyErr_SetObject`.
<antocuni>
fangerer: so basically, HPyErr_Format will be part of the API but not of the ABI, like HPyArg_Parse?
<fangerer>
yes (that's my current and rough idea)
<antocuni>
I think it could work, but we need to take some care
<fangerer>
what do you have in mind?
<antocuni>
e.g., if you look at CPython's implementation of PyErr_Format you see that it's written very carefully
<antocuni>
like, there is a comment in _PyErr_FormatV which explains that it needs to call _PyErr_Clear() because of isue 23571
<fangerer>
Okay, makes sense. You often want to create an exception while handling another exception.
<antocuni>
I'm not 100% sure that it makes sense and if I had to design from scratch I would probably say that you cannot and that you have to clear the exception manually
<antocuni>
I'm not sure what is the best for HPy though
<fangerer>
different topic: since we (GraalVM) have feature freeze soon (Sept 17th) we should create the `0.0.3` release branch soon. I'll review the GitHub Actions PR soon (which we said should be included in the release).
<antocuni>
+1 for me
<antocuni>
fwiw, I don't plan to do any actual HPy work in september, apart from reviewing some PRs and discussing things here