Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
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
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.
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list