I've reread PEP 282 (the logging PEP) and much of what I read
reminded me of the warning framework.
Both systems are responsible for reporting (or ignoring) messages.
Both associate messages with locations in the source where the
messages originated and both have a way to configure what to report
and what to ignore.
So I guess it would make sense to somehow merge the two APIs.
And looking at the warning framework suggests a different way
of handling log levels/types: Instead of specifying types
with integer constants and configuring what to log with a
threshold value, we could have a class hierarchy of message
types similar to the hierarchy for warning types:
class Message(Exeption):
pass
class InfoMessage(Message):
pass
class ErrorMessage(InfoMessage):
pass
class FatalMessage(ErrorMessage):
pass
This hierarchy is customizable with user defined classes:
class ResourceMessage(FatalMessage):
pass
class DiskFullMessage(ResourceMessage):
pass
class OutOfMemoryMessage(ResourceMessage):
pass
Configuration would be similar to the configuration for the
warnings framework, i.e. it would be possible to specify which
Message classes should be logged and which shouldn't: The filter
simply calls isinstance() to check if the message should
be logged.
Calling the logging function would be similar to calling
warnings.warn: You can either pass a message string and a
message class or a message instance, i.e.
logger.log("disk full", log.DiskFullMessage)
or
logger.log(log.DiskFullMessage("disk full"))
Logging exceptions with this API is then simple and natural:
logger.log(ExceptionClass("message"))
Does this make sense and if yes, do we still have time to change
the PEP/implementation until 2.3?
Bye,
Walter Dörwald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4