Source code
logger: FilteringBoundLogger = structlog.getLogger("example")
log = logger.bind(foo="bar")
log.is_enabled_for(logging.DEBUG) # or log.isEnabledFor(logging.DEBUG)
Now
Given how structlog works, under different conditions the same log variable can be either BoundLogger or BoundLoggerFilteringAtNotset.
So, in one environment the same line of code will fail with
AttributeError: 'BoundLoggerFilteringAtNotset' object has no attribute 'isEnabledFor'. Did you mean: 'is_enabled_for'?
and in another environment, the same line of code will fail with
AttributeError: 'BoundLogger' object has no attribute 'is_enabled_for'. Did you mean: 'isEnabledFor'?
🤷
Feature request
Can we ensure consistent behavior across all classes? It would be great if they either all support both isEnabledFor and is_enabled_for, or all strictly adhere to just one of these methods.
Versions
- structlog 25.5.0
- Python 3.13.11
Source code
Now
Given how
structlogworks, under different conditions the samelogvariable can be eitherBoundLoggerorBoundLoggerFilteringAtNotset.So, in one environment the same line of code will fail with
and in another environment, the same line of code will fail with
🤷
Feature request
Can we ensure consistent behavior across all classes? It would be great if they either all support both
isEnabledForandis_enabled_for, or all strictly adhere to just one of these methods.Versions