This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients cheryl.sabella, serhiy.storchaka, terry.reedy
Date 2018-02-15.02:21:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
A person who can create a tcl callback with can inquire with'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.)
Date User Action Args
2018-02-15 02:21:54terry.reedysetrecipients: + terry.reedy, serhiy.storchaka, cheryl.sabella
2018-02-15 02:21:54terry.reedysetmessageid: <>
2018-02-15 02:21:54terry.reedylinkissue32839 messages
2018-02-15 02:21:52terry.reedycreate