A topic-centered debugging facility #28

Open
opened 2022-10-20 08:34:38 +02:00 by ni · 1 comment
ni commented 2022-10-20 08:34:38 +02:00 (Migrated from git.w21.org)

For more complex applications, a simple overall debug/verbosity level is not helpful when you want to see some aspects of the application more detailed and others not. I have used a debug flag/topic based approach as early as 1999 (that mail thing) with success. Of course in C, it wasn't easy to implement this generically, and I didn't even try that (but had a table-driven easily extensible approach). In Python it is, so I'll do it.

The idea is that I have a number of debug flags or topics (I'll stick to the latter term here) that are defined beforehand. This way we can conventiently use debug.<topic>(*things) from the start and need not check if that exists or use a clumsier syntax (as in e.g. debug("topic", *things)) to address a topic.

Functions could look like this, using string Tokens for topic indentifiers:

debug_topics(*topics)    # so we have debug.<topic>(); return list of topics
debug_on(*topics)        # switch on debug topic(s); return list of enabled topics
debug_off(*topics)       # switch off debug topic(s)
debug.<topic>(*msgs)     # print debug message if topic is on

Or a debugger class/object on which topics can be defined:

dbg = TopicDebugger(*topics)
dbg.switch_on(*topics)
dbg.switch_off(*topics)
dbg.<topic>(*msgs)

Topics can then be switched on/off e.g. via command line options or some run time mechanism like a CLI or API.

For more complex applications, a simple overall debug/verbosity level is not helpful when you want to see some aspects of the application more detailed and others not. I have used a debug flag/topic based approach as early as 1999 (that mail thing) with success. Of course in C, it wasn't easy to implement this generically, and I didn't even try that (but had a table-driven easily extensible approach). In Python it is, so I'll do it. The idea is that I have a number of debug flags or topics (I'll stick to the latter term here) that are defined beforehand. This way we can conventiently use `debug.<topic>(*things)` from the start and need not check if that exists or use a clumsier syntax (as in e.g. `debug("topic", *things)`) to address a topic. Functions could look like this, using string Tokens for topic indentifiers: ``` debug_topics(*topics) # so we have debug.<topic>(); return list of topics debug_on(*topics) # switch on debug topic(s); return list of enabled topics debug_off(*topics) # switch off debug topic(s) debug.<topic>(*msgs) # print debug message if topic is on ``` _Or_ a debugger class/object on which topics can be defined: ``` dbg = TopicDebugger(*topics) dbg.switch_on(*topics) dbg.switch_off(*topics) dbg.<topic>(*msgs) ``` Topics can then be switched on/off e.g. via command line options or some run time mechanism like a CLI or API.
ni commented 2022-10-20 08:34:39 +02:00 (Migrated from git.w21.org)

assigned to @ni

assigned to @ni
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
w21/jpylib#28
No description provided.