Nathaniel J. Smith

That's a conflict between SRILM code (`srilm/include/zio.h`) and OS X system code (`/usr/include/stdio.h`) -- not much that pysrilm can do about it as far as I can see :-(. pysrilm...

> I am currently trying to make to work lots of bindings but none seem to work... Yes, because the problem is on SRILM, not in the bindings :-). You...

Pasting from that comment: ```python try: ... except: @ExceptionGroup.handle(FooException) def handler(exc): ... ``` One limitation of this approach is that `handler` has to be synchronous. Python doesn't have "async decorators"....

Unfortunately, the ExceptionGroup catching code is extremely complex, due to all the hacks it has to use to convince python's hard-coded exception-handling not to interfere. For example: if the custom...

Is the idea that you would chain these to handle multiple exceptions, like this? ```python try: ... except: with get_exception() as group: if ex := handle(group, OSError): raise OtherException if...

You mean, something like this? ```python try: ... except: with open_handler() as handler: with handler.handle(OSError) as exc: raise OtherException with handler.handle(ValueError) as exc: log(exc) ``` This version does have a...

Another interesting trade-off between these different approaches: normally in py3, when you write `except ... as exc:`, the `exc` variable is cleared at the end of the `except` block. (I...

Another option to consider is a hybrid: ```python try: ... except: async with open_handler() as handler: @handler.handle(OSError) def handler(exc): ... @handler.handle(RuntimeError) async def handler(exc): ... ```

Btw, there is no reliable way to get from a function object to its AST :-(

@WindSoilder asked for more details on the actual semantics of these different ideas. Fair question! :-) Normally when people want to handle an exception, they write something like: ```python try:...