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.)