Serhiy Storchaka <> 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 <>
Python-bugs-list mailing list

Reply via email to