Stephen Macke

Hmm, might be necessary to run `%load_ext ipyflow` on colab first; I'll take a look soon to try and figure out what's going on (responding from mobile at the moment).

Couldn't resist and just took a quick look. Seems that on colab, there's something about the ipyflow kernel subclass that conflicts with colab's own kernel subclass, which is why the...

I'm actually going to keep this open because the kernel incompatibility looks like it's a genuine bug (and fixable, fortunately)

`%load_ext ipyflow` now works on the latest version of ipyflow (i.e. instead of `%load_ext ipyflow.shell`), but it looks like getting this kind of support automatically when the runtime is selected...

@rlue this is probably not an issue with ffsubsync or with ffmpeg-python, but with the version of the [future](https://github.com/PythonCharmers/python-future/) package you have installed. You should see an improvement after running...

I haven't looked carefully enough at the original issue but for `TypeError: structured_traceback() missing 1 required positional argument: 'evalue'`, I think https://github.com/ipython/ipython/pull/14453 can help

> I was going to say we still have some downstream users we care about still support Python 2, but now I see that ffsubsync that I was thinking of...

I think this is only an issue for callbacks that throw exceptions (functions created in notebook and then passed down and called in library code; e.g. function passed to list.map).

Actually this is particularly important during interrupts. Edited title to reflect this.

Ah, "pull-based" reactivity rather than "push-based". I've thought about it before as well -- should be possible to support, in theory. It's a bit tricky because the previous dependency structure...