Revision 1577
Jump to revision: |
|
Author: |
pje |
Date: |
Sun Dec 28 20:58:28 2003 UTC (20 years, 4 months ago) |
Log Message:
First pass of 'logs' framework refactoring. Highlights include:
* Lots of new unit tests for logging.
* Logs are now accessed via a 'logs.ILoggingService' instance. The
'logger:' URL scheme automatically accesses the nearest such service.
For backward compatibility, the old 'peak.logs' namespace is still used
to supply the actual loggers. This will be gradually replaced with a
plugin-based mechanism.
* Log events don't use a positional 'message' argument any more, and
loggers aren't responsible for interpolating message arguments any more.
The new signature is 'Event(parent, msg=msg, args=args, ...)'. Loggers
also now tell events what logger name they are, via the 'ident' keyword.
* The logging system now uses a property namespace, 'peak.logging.levels',
to obtain log level names and values. The various 'logs.LEVEL'
constants are now DEPRECATED. Please use the 'getLevelFor()' method of
the nearest 'logs.ILoggingService' instead. URL schemes such as
'logfile:' also no longer convert their level names to numbers, since
the level names are only meaningful in the context of a logging service.
* Support for integration with the Python 2.3/PEP 282 logging module has
been scaled back. There are too many globalisms and dependencies there.
When we add plugin-based log configuration, it should be possible to use
the logging package's handlers and formatters with the PEAK logging
services. At that point, you'll be able to replace 'logging.getLogger'
and 'logging.getLevelName' with the corresponding methods of a PEAK
logging service, if you need to force non-PEAK packages to use PEAK's
logging.
* 'config.Namespace()' objects now have a 'keys()' method that can be used
when the namespace is bound to a context component. It returns a list
of strings that may be used as keys for that namespace. See
'CHANGES.txt' for an example.
Changed paths: