On one side, the first item of the list returned by the Tcl command `after info $id` is a name of the Tcl command generated by Tkinter. It is internal, it was not exposed to Tkinter users before, and the API for restoring the original Python callable is private.

On other side, `after info` can return not only events created by Tkinter, but events created by Tcl (either by direct execution of Tcl script, this is still can be useful with programming with Tkinter, or created by the Tcl standard library or third-party Tcl libraries). In that case a Python callable can't be returned.

This is what I was uncertain about. Maybe after_info() should return a Python callable if possible, and keep the original result otherwise? This complicates its implementation and definition.

TclError is legal and expected. In some methods it is caught, either because the method is purposed to be called at widget destroying stage, when the order of different cleanup procedures is not specified, and Tcl names can be destroyed before destroying Tkinter wrappers, or because the method was implemented differently in the past, and catching TclError is needed for backward compatibility. after_info() is not the case.