You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ROADMAP.md
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,12 +23,14 @@ Some of these we just want to consider, and may not want to implement.
23
23
24
24
## 🔌 API
25
25
- Evaluate `_applyPropagateSetting()` and its relationship with `__init__`: Currently, `Logger.__init__()` sets `_propagate_set = False` when `propagate=None`, indicating that `_applyPropagateSetting()` will set it later. This creates a two-phase initialization where propagate can be set either in `__init__` or later via `_applyPropagateSetting()`. Evaluate whether this split responsibility is clear and maintainable, or if propagate should always be set in `__init__` with the registry/default value passed directly. Consider the complexity of tracking `_propagate_set` flag and whether there are edge cases where the propagate value might be inconsistent or set at unexpected times.
26
-
-**Root logger replacement: porting handlers and level:** When `extendLoggingModule()` replaces the root logger with an apathetic logger, we currently preserve the old root logger's level, handlers, propagate, and disabled state. Evaluate whether this behavior should be configurable:
27
-
- Should we port handlers by default, or should the new apathetic root logger start fresh with its own handlers (via `manageHandlers()`)?
28
-
- Should we port the level by default, or should the new root logger use a default level (NOTSET/INHERIT)?
29
-
- If we make this configurable, do we need keyword arguments to `extendLoggingModule()`, registry settings, or constants for these scenarios?
30
-
- Should users be able to specify they want handlers/level ported, or does porting them not make good sense at all (e.g., because apathetic loggers should manage their own handlers)?
31
-
- Consider edge cases: What if the old root logger has incompatible handlers? What if the level was set to a custom value that doesn't exist in apathetic logging?
26
+
-**Root logger replacement: edge cases with custom logger classes:** Review and test situations where we replace the root logger, especially when the default logger class (set via `logging.setLoggerClass()`) is:
27
+
- Not a stdlib `logging.Logger` (e.g., a completely different class)
28
+
- A different subclass of `logging.Logger` (e.g., a third-party logger class)
29
+
- A subclass of our apathetic logger (e.g., `class MyLogger(apathetic_logging.Logger): pass`)
30
+
- Verify that our `isinstance(root_logger, cls)` check in `extendLoggingModule()` correctly identifies when replacement is needed
31
+
- Ensure state porting works correctly when replacing loggers of different types
32
+
- Test behavior when `replace_root=False` is set but the root logger is a different type
33
+
- Consider whether we should warn or error when replacing a logger that's a subclass of our apathetic logger (might indicate user wants to use their subclass)
0 commit comments