I’m looking into implementing except* in Cython. Most of it’s relatively straight-forward (I hope) but a big chunk of the important logic is in _PyExc_PrepReraiseStar and it doesn’t seem possible to access that without including internal headers (which is never popular).

It’d probably be possible to reimplement the logic for it myself, but it’s obviously quite a large chunk of code to be copying and trying to keep up to date.

Would it be possible to expose this more publicly? This is unlikely to be performance critical so, even something as simple as a method on BaseExceptionGroup that’s accessible from Python would do.

(For the moment I’m probably just doing to do the internal header access, but it’d be nice to be able to do it right in future)

I think this function, along with the other intrinsics (which are functions that implement an opcode) can be exposed as part of the ‘unstable API’. I’m not sure where we are on having that?

Could you create an issue about this as part of the c API discussions? Needing to re-implement the interpreter is a particular use case, which we should probably cover in general, beyond just the except* business. The bytecode definitions DSL is a part of this story.

Thanks - I’ve created the issue. https://github.com/capi-workgroup/problems/issues/40

I’ve added

I’d slightly disagree with this interpretation - while it looks like _PyExc_PrepReraiseStar is an intrinsic, it also seems like something that can be done to an instance of BaseExceptionGroup independently of the bytecode (although practically I don’t know why you’d want to except for reimplementing the interpreter).

Except for this one intrinsic, I don’t recall seeing any others that Cython has wanted to use directly. While we often do very similar things, we don’t always draw do it exactly aligned with Python’s own bytecodes. This one case is exceptional because it’s a pretty self-contained operation. So I’ve kept the focus of the issue to just this one function rather than all the intrinsics.

1 Like

We have that in 3.12: devguide, user docs.
Use the PyUnstable_ prefix, and add full docs (so it’s usable by others) & tests (so it doesn’t break unexpectedly).
You can even add unstable API for an existing feature in the Beta period (with consensus here on Discourse) :‍)


Thanks. So we can still add this to 3.12.

I’ve got a bit further with the Cython implementation and found that _PyExc_PrepReraiseStar seems to have hidden visibility for some reason (despite being declared with PyAPI_FUNC). I’m not sure I understand why, but that’s probably not hugely important.

I think that means I have to reimplement it myself to get something that’ll work on the already released Python 3.11 versions.

I suspect it’s probably still worth exposing the official implementation of it, to get more reliable tracking of any future changes. But it becomes a little lower priority for me because the “use the internal implementation initially → formalize the internal implementation” approach doesn’t look viable.

I’m still doing a bit of investigating though…

I wonder why too.

I’ve created a PR.

Thanks for that.

Still working on the Cython implementation, but I’ll point it to use that function once it’s available.