Terry J. Reedy <tjre...@udel.edu> added the comment:
A person who can create a tcl callback with tk.call can inquire with
tk.call('after', 'info', id). That does not cover callbacks created by tcl or
extensions thereof, but references to such callbacks are unlikely to be useful
to anyone who does not know any tcl.
I see these choices for after_info(id):
A. Return the tcl script reference even when it wraps a python function. I
don't like this, as the tcl reference is useless to most people.
B. Convert the reference to a Python function if possible but return it if not.
This is a bit awkward to document and any use requires a type check. Having a
function return such different types, depending on the input, is frowned upon.
C. Convert the reference to a function if possibe and raise TypeError or
ValueError is not. This is incomplete but easier for a pure Python programmer
to deal with. The documentation could specify how those who want a tcl
reference can get it.
D. Don't implement after_info(id), at least not now, and just after_info().
Information about the current existence of a callback is contained in the list
returned by after_info(). Each of the following pairs should be equivalent:
assertIn(id, after_info())
assertEqual(len(after_info(id)), 2)
assertNotIn(id, after_info())
assertRaises(TclError, after_info, id)
(For testing after_info(), assertIn and assertNotIn avoid assuming that tcl
does not add any internal callbacks.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32839>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
