Logger Objects¶

Loggers have the following attributes and methods. Note that Loggers shouldNEVER be instantiated directly, but always through the module-level functionlogging.getLogger(name). Multiple calls togetLogger() with the samename will always return a reference to the same Logger object.

Thename is potentially a period-separated hierarchical value, likefoo.bar.baz (though it could also be just plainfoo, for example).Loggers that are further down in the hierarchical list are children of loggershigher up in the list. For example, given a logger with a name offoo,loggers with names offoo.bar,foo.bar.baz, andfoo.bam are alldescendants offoo. The logger name hierarchy is analogous to the Pythonpackage hierarchy, and identical to it if you organise your loggers on aper-module basis using the recommended constructionlogging.getLogger(__name__). That’s because in a module,__name__is the module’s name in the Python package namespace.

classlogging.Logger¶

propagate¶

If this attribute evaluates to true, events logged to this logger will bepassed to the handlers of higher level (ancestor) loggers, in addition toany handlers attached to this logger. Messages are passed directly to theancestor loggers’ handlers - neither the level nor filters of the ancestorloggers in question are considered.

If this evaluates to false, logging messages are not passed to the handlersof ancestor loggers.

The constructor sets this attribute toTrue.

Note

If you attach a handler to a loggerand one or more of itsancestors, it may emit the same record multiple times. In general, youshould not need to attach a handler to more than one logger - if you justattach it to the appropriate logger which is highest in the loggerhierarchy, then it will see all events logged by all descendant loggers,provided that their propagate setting is left set toTrue. A commonscenario is to attach handlers only to the root logger, and to letpropagation take care of the rest.

setLevel(level)¶

Sets the threshold for this logger tolevel. Logging messages which are lesssevere thanlevel will be ignored; logging messages which have severitylevelor higher will be emitted by whichever handler or handlers service this logger,unless a handler’s level has been set to a higher severity level thanlevel.

When a logger is created, the level is set toNOTSET (which causesall messages to be processed when the logger is the root logger, or delegationto the parent when the logger is a non-root logger). Note that the root loggeris created with levelWARNING.

The term ‘delegation to the parent’ means that if a logger has a level ofNOTSET, its chain of ancestor loggers is traversed until either an ancestor witha level other than NOTSET is found, or the root is reached.

If an ancestor is found with a level other than NOTSET, then that ancestor’slevel is treated as the effective level of the logger where the ancestor searchbegan, and is used to determine how a logging event is handled.

If the root is reached, and it has a level of NOTSET, then all messages will beprocessed. Otherwise, the root’s level will be used as the effective level.

SeeLogging Levels for a list of levels.

Changed in version 3.2:Thelevel parameter now accepts a string representation of thelevel such as ‘INFO’ as an alternative to the integer constantssuch asINFO. Note, however, that levels are internally storedas integers, and methods such as e.g.getEffectiveLevel() andisEnabledFor() will return/expect to be passed integers.

isEnabledFor(level)¶

Indicates if a message of severitylevel would be processed by this logger.This method checks first the module-level level set bylogging.disable(level) and then the logger’s effective level as determinedbygetEffectiveLevel().

getEffectiveLevel()¶

Indicates the effective level for this logger. If a value other thanNOTSET has been set usingsetLevel(), it is returned. Otherwise,the hierarchy is traversed towards the root until a value other thanNOTSET is found, and that value is returned. The value returned isan integer, typically one oflogging.DEBUG,logging.INFOetc.

getChild(suffix)¶

Returns a logger which is a descendant to this logger, as determined by the suffix.Thus,logging.getLogger('abc').getChild('def.ghi') would return the samelogger as would be returned bylogging.getLogger('abc.def.ghi'). This is aconvenience method, useful when the parent logger is named using e.g.__name__rather than a literal string.

New in version 3.2.

debug(msg,*args,**kwargs)¶

Logs a message with levelDEBUG on this logger. Themsg is themessage format string, and theargs are the arguments which are merged intomsg using the string formatting operator. (Note that this means that you canuse keywords in the format string, together with a single dictionary argument.)No % formatting operation is performed onmsg when noargs are supplied.

There are four keyword arguments inkwargs which are inspected:exc_info,stack_info,stacklevel andextra.

Ifexc_info does not evaluate as false, it causes exception information to beadded to the logging message. If an exception tuple (in the format returned bysys.exc_info()) or an exception instance is provided, it is used;otherwise,sys.exc_info() is called to get the exception information.

The second optional keyword argument isstack_info, which defaults toFalse. If true, stack information is added to the loggingmessage, including the actual logging call. Note that this is not the samestack information as that displayed through specifyingexc_info: Theformer is stack frames from the bottom of the stack up to the logging callin the current thread, whereas the latter is information about stack frameswhich have been unwound, following an exception, while searching forexception handlers.

You can specifystack_info independently ofexc_info, e.g. to just showhow you got to a certain point in your code, even when no exceptions wereraised. The stack frames are printed following a header line which says:

Stack (most recent call last):

This mimics theTraceback(mostrecentcalllast): which is used whendisplaying exception frames.

The third optional keyword argument isstacklevel, which defaults to1.If greater than 1, the corresponding number of stack frames are skippedwhen computing the line number and function name set in theLogRecordcreated for the logging event. This can be used in logging helpers so thatthe function name, filename and line number recorded are not the informationfor the helper function/method, but rather its caller. The name of thisparameter mirrors the equivalent one in thewarnings module.

The fourth keyword argument isextra which can be used to pass adictionary which is used to populate the __dict__ of theLogRecordcreated for the logging event with user-defined attributes. These customattributes can then be used as you like. For example, they could beincorporated into logged messages. For example:

FORMAT='%(asctime)-15s%(clientip)s%(user)-8s%(message)s'logging.basicConfig(format=FORMAT)d={'clientip':'192.168.0.1','user':'fbloggs'}logger=logging.getLogger('tcpserver')logger.warning('Protocol problem:%s','connection reset',extra=d)

would print something like

2006-02-08 22:20:02,165 192.168.0.1 fbloggs  Protocol problem: connection reset

The keys in the dictionary passed inextra should not clash with the keys usedby the logging system. (See theFormatter documentation for moreinformation on which keys are used by the logging system.)

If you choose to use these attributes in logged messages, you need to exercisesome care. In the above example, for instance, theFormatter has beenset up with a format string which expects ‘clientip’ and ‘user’ in the attributedictionary of theLogRecord. If these are missing, the message willnot be logged because a string formatting exception will occur. So in this case,you always need to pass theextra dictionary with these keys.

While this might be annoying, this feature is intended for use in specializedcircumstances, such as multi-threaded servers where the same code executes inmany contexts, and interesting conditions which arise are dependent on thiscontext (such as remote client IP address and authenticated user name, in theabove example). In such circumstances, it is likely that specializedFormatters would be used with particularHandlers.

Changed in version 3.2:Thestack_info parameter was added.

Changed in version 3.5:Theexc_info parameter can now accept exception instances.

Changed in version 3.8:Thestacklevel parameter was added.

info(msg,*args,**kwargs)¶

Logs a message with levelINFO on this logger. The arguments areinterpreted as fordebug().

warning(msg,*args,**kwargs)¶

Logs a message with levelWARNING on this logger. The arguments areinterpreted as fordebug().

Note

There is an obsolete methodwarn which is functionallyidentical towarning. Aswarn is deprecated, please do not useit - usewarning instead.

error(msg,*args,**kwargs)¶

Logs a message with levelERROR on this logger. The arguments areinterpreted as fordebug().

critical(msg,*args,**kwargs)¶

Logs a message with levelCRITICAL on this logger. The arguments areinterpreted as fordebug().

log(level,msg,*args,**kwargs)¶

Logs a message with integer levellevel on this logger. The other arguments areinterpreted as fordebug().

exception(msg,*args,**kwargs)¶

Logs a message with levelERROR on this logger. The arguments areinterpreted as fordebug(). Exception info is added to the loggingmessage. This method should only be called from an exception handler.

addFilter(filter)¶

Adds the specified filterfilter to this logger.

removeFilter(filter)¶

Removes the specified filterfilter from this logger.

filter(record)¶

Apply this logger’s filters to the record and returnTrue if therecord is to be processed. The filters are consulted in turn, until one ofthem returns a false value. If none of them return a false value, the recordwill be processed (passed to handlers). If one returns a false value, nofurther processing of the record occurs.

addHandler(hdlr)¶

Adds the specified handlerhdlr to this logger.

removeHandler(hdlr)¶

Removes the specified handlerhdlr from this logger.

findCaller(stack_info=False,stacklevel=1)¶

Finds the caller’s source filename and line number. Returns the filename, linenumber, function name and stack information as a 4-element tuple. The stackinformation is returned asNone unlessstack_info isTrue.

Thestacklevel parameter is passed from code calling thedebug()and other APIs. If greater than 1, the excess is used to skip stack framesbefore determining the values to be returned. This will generally be usefulwhen calling logging APIs from helper/wrapper code, so that the informationin the event log refers not to the helper/wrapper code, but to the code thatcalls it.

handle(record)¶

Handles a record by passing it to all handlers associated with this logger andits ancestors (until a false value ofpropagate is found). This method is usedfor unpickled records received from a socket, as well as those created locally.Logger-level filtering is applied usingfilter().

makeRecord(name,level,fn,lno,msg,args,exc_info,func=None,extra=None,sinfo=None)¶

This is a factory method which can be overridden in subclasses to createspecializedLogRecord instances.

hasHandlers()¶

Checks to see if this logger has any handlers configured. This is done bylooking for handlers in this logger and its parents in the logger hierarchy.ReturnsTrue if a handler was found, elseFalse. The method stops searchingup the hierarchy whenever a logger with the ‘propagate’ attribute set tofalse is found - that will be the last logger which is checked for theexistence of handlers.

New in version 3.2.

Changed in version 3.7:Loggers can now be pickled and unpickled.

Logging Levels¶

The numeric values of logging levels are given in the following table. These areprimarily of interest if you want to define your own levels, and need them tohave specific values relative to the predefined levels. If you define a levelwith the same numeric value, it overwrites the predefined value; the predefinedname is lost.

Handler Objects¶

Handlers have the following attributes and methods. Note thatHandleris never instantiated directly; this class acts as a base for more usefulsubclasses. However, the__init__() method in subclasses needs to callHandler.__init__().

classlogging.Handler¶

__init__(level=NOTSET)¶

Initializes theHandler instance by setting its level, setting the listof filters to the empty list and creating a lock (usingcreateLock()) forserializing access to an I/O mechanism.

createLock()¶

Initializes a thread lock which can be used to serialize access to underlyingI/O functionality which may not be threadsafe.

acquire()¶

Acquires the thread lock created withcreateLock().

release()¶

Releases the thread lock acquired withacquire().

setLevel(level)¶

Sets the threshold for this handler tolevel. Logging messages which areless severe thanlevel will be ignored. When a handler is created, thelevel is set toNOTSET (which causes all messages to beprocessed).

SeeLogging Levels for a list of levels.

Changed in version 3.2:Thelevel parameter now accepts a string representation of thelevel such as ‘INFO’ as an alternative to the integer constantssuch asINFO.

setFormatter(fmt)¶

Sets theFormatter for this handler tofmt.

addFilter(filter)¶

Adds the specified filterfilter to this handler.

removeFilter(filter)¶

Removes the specified filterfilter from this handler.

filter(record)¶

Apply this handler’s filters to the record and returnTrue if therecord is to be processed. The filters are consulted in turn, until one ofthem returns a false value. If none of them return a false value, the recordwill be emitted. If one returns a false value, the handler will not emit therecord.

flush()¶

Ensure all logging output has been flushed. This version does nothing and isintended to be implemented by subclasses.

close()¶

Tidy up any resources used by the handler. This version does no output butremoves the handler from an internal list of handlers which is closed whenshutdown() is called. Subclasses should ensure that this gets calledfrom overriddenclose() methods.

handle(record)¶

Conditionally emits the specified logging record, depending on filters which mayhave been added to the handler. Wraps the actual emission of the record withacquisition/release of the I/O thread lock.

handleError(record)¶

This method should be called from handlers when an exception is encounteredduring anemit() call. If the module-level attributeraiseExceptions isFalse, exceptions get silently ignored. This iswhat is mostly wanted for a logging system - most users will not care abouterrors in the logging system, they are more interested in applicationerrors. You could, however, replace this with a custom handler if you wish.The specified record is the one which was being processed when the exceptionoccurred. (The default value ofraiseExceptions isTrue, as that ismore useful during development).

format(record)¶

Do formatting for a record - if a formatter is set, use it. Otherwise, use thedefault formatter for the module.

emit(record)¶

Do whatever it takes to actually log the specified logging record. This versionis intended to be implemented by subclasses and so raises aNotImplementedError.

For a list of handlers included as standard, seelogging.handlers.

Formatter Objects¶

Formatter objects have the following attributes and methods. They areresponsible for converting aLogRecord to (usually) a string which canbe interpreted by either a human or an external system. The baseFormatter allows a formatting string to be specified. If none issupplied, the default value of'%(message)s' is used, which just includesthe message in the logging call. To have additional items of information in theformatted output (such as a timestamp), keep reading.

A Formatter can be initialized with a format string which makes use of knowledgeof theLogRecord attributes - such as the default value mentioned abovemaking use of the fact that the user’s message and arguments are pre-formattedinto aLogRecord’smessage attribute. This format string containsstandard Python %-style mapping keys. See sectionprintf-style String Formattingfor more information on string formatting.

The useful mapping keys in aLogRecord are given in the section onLogRecord attributes.

classlogging.Formatter(fmt=None,datefmt=None,style='%')¶

Returns a new instance of theFormatter class. The instance isinitialized with a format string for the message as a whole, as well as aformat string for the date/time portion of a message. If nofmt isspecified,'%(message)s' is used. If nodatefmt is specified, a formatis used which is described in theformatTime() documentation.

Thestyle parameter can be one of ‘%’, ‘{’ or ‘$’ and determines howthe format string will be merged with its data: using one of %-formatting,str.format() orstring.Template. SeeUsing particular formatting styles throughout your applicationfor more information on using {- and $-formatting for log messages.

Changed in version 3.2:Thestyle parameter was added.

Changed in version 3.8:Thevalidate parameter was added. Incorrect or mismatched style and fmtwill raise aValueError.For example:logging.Formatter('%(asctime)s-%(message)s',style='{').

format(record)¶

The record’s attribute dictionary is used as the operand to a stringformatting operation. Returns the resulting string. Before formatting thedictionary, a couple of preparatory steps are carried out. Themessageattribute of the record is computed usingmsg %args. If theformatting string contains'(asctime)',formatTime() is calledto format the event time. If there is exception information, it isformatted usingformatException() and appended to the message. Notethat the formatted exception information is cached in attributeexc_text. This is useful because the exception information can bepickled and sent across the wire, but you should be careful if you havemore than oneFormatter subclass which customizes the formattingof exception information. In this case, you will have to clear the cachedvalue after a formatter has done its formatting, so that the nextformatter to handle the event doesn’t use the cached value butrecalculates it afresh.

If stack information is available, it’s appended after the exceptioninformation, usingformatStack() to transform it if necessary.

formatTime(record,datefmt=None)¶

This method should be called fromformat() by a formatter whichwants to make use of a formatted time. This method can be overridden informatters to provide for any specific requirement, but the basic behavioris as follows: ifdatefmt (a string) is specified, it is used withtime.strftime() to format the creation time of therecord. Otherwise, the format ‘%Y-%m-%d %H:%M:%S,uuu’ is used, where theuuu part is a millisecond value and the other letters are as per thetime.strftime() documentation. An example time in this format is2003-01-2300:29:50,411. The resulting string is returned.

This function uses a user-configurable function to convert the creationtime to a tuple. By default,time.localtime() is used; to changethis for a particular formatter instance, set theconverter attributeto a function with the same signature astime.localtime() ortime.gmtime(). To change it for all formatters, for example if youwant all logging times to be shown in GMT, set theconverterattribute in theFormatter class.

Changed in version 3.3:Previously, the default format was hard-coded as in this example:2010-09-0622:38:15,292 where the part before the comma ishandled by a strptime format string ('%Y-%m-%d%H:%M:%S'), and thepart after the comma is a millisecond value. Because strptime does nothave a format placeholder for milliseconds, the millisecond value isappended using another format string,'%s,%03d' — and both of theseformat strings have been hardcoded into this method. With the change,these strings are defined as class-level attributes which can beoverridden at the instance level when desired. The names of theattributes aredefault_time_format (for the strptime format string)anddefault_msec_format (for appending the millisecond value).

formatException(exc_info)¶

Formats the specified exception information (a standard exception tuple asreturned bysys.exc_info()) as a string. This default implementationjust usestraceback.print_exception(). The resulting string isreturned.

formatStack(stack_info)¶

Formats the specified stack information (a string as returned bytraceback.print_stack(), but with the last newline removed) as astring. This default implementation just returns the input value.

Filter Objects¶

Filters can be used byHandlers andLoggers for more sophisticatedfiltering than is provided by levels. The base filter class only allows eventswhich are below a certain point in the logger hierarchy. For example, a filterinitialized with ‘A.B’ will allow events logged by loggers ‘A.B’, ‘A.B.C’,‘A.B.C.D’, ‘A.B.D’ etc. but not ‘A.BB’, ‘B.A.B’ etc. If initialized with theempty string, all events are passed.

classlogging.Filter(name='')¶

Returns an instance of theFilter class. Ifname is specified, itnames a logger which, together with its children, will have its events allowedthrough the filter. Ifname is the empty string, allows every event.

filter(record)¶

Is the specified record to be logged? Returns zero for no, nonzero foryes. If deemed appropriate, the record may be modified in-place by thismethod.

Note that filters attached to handlers are consulted before an event isemitted by the handler, whereas filters attached to loggers are consultedwhenever an event is logged (usingdebug(),info(),etc.), before sending an event to handlers. This means that events which havebeen generated by descendant loggers will not be filtered by a logger’s filtersetting, unless the filter has also been applied to those descendant loggers.

You don’t actually need to subclassFilter: you can pass any instancewhich has afilter method with the same semantics.

Although filters are used primarily to filter records based on moresophisticated criteria than levels, they get to see every record which isprocessed by the handler or logger they’re attached to: this can be useful ifyou want to do things like counting how many records were processed by aparticular logger or handler, or adding, changing or removing attributes intheLogRecord being processed. Obviously changing the LogRecord needsto be done with some care, but it does allow the injection of contextualinformation into logs (seeUsing Filters to impart contextual information).

LogRecord Objects¶

LogRecord instances are created automatically by theLoggerevery time something is logged, and can be created manually viamakeLogRecord() (for example, from a pickled event received over thewire).

classlogging.LogRecord(name,level,pathname,lineno,msg,args,exc_info,func=None,sinfo=None)¶

Contains all the information pertinent to the event being logged.

The primary information is passed inmsg andargs, whichare combined usingmsg%args to create themessage field of therecord.

Parameters

• name – The name of the logger used to log the event represented bythis LogRecord. Note that this name will always have thisvalue, even though it may be emitted by a handler attached toa different (ancestor) logger.

• level – The numeric level of the logging event (one of DEBUG, INFO etc.)Note that this is converted totwo attributes of the LogRecord:levelno for the numeric value andlevelname for thecorresponding level name.

• pathname – The full pathname of the source file where the logging callwas made.

• lineno – The line number in the source file where the logging call wasmade.

• msg – The event description message, possibly a format string withplaceholders for variable data.

• args – Variable data to merge into themsg argument to obtain theevent description.

• exc_info – An exception tuple with the current exception information,orNone if no exception information is available.

• func – The name of the function or method from which the logging callwas invoked.

• sinfo – A text string representing stack information from the base ofthe stack in the current thread, up to the logging call.

getMessage()¶

Returns the message for thisLogRecord instance after merging anyuser-supplied arguments with the message. If the user-supplied messageargument to the logging call is not a string,str() is called on it toconvert it to a string. This allows use of user-defined classes asmessages, whose__str__ method can return the actual format string tobe used.

Changed in version 3.2:The creation of aLogRecord has been made more configurable byproviding a factory which is used to create the record. The factory can beset usinggetLogRecordFactory() andsetLogRecordFactory()(see this for the factory’s signature).

This functionality can be used to inject your own values into aLogRecord at creation time. You can use the following pattern:

old_factory=logging.getLogRecordFactory()defrecord_factory(*args,**kwargs):record=old_factory(*args,**kwargs)record.custom_attribute=0xdecafbadreturnrecordlogging.setLogRecordFactory(record_factory)

With this pattern, multiple factories could be chained, and as longas they don’t overwrite each other’s attributes or unintentionallyoverwrite the standard attributes listed above, there should be nosurprises.

LogRecord attributes¶

The LogRecord has a number of attributes, most of which are derived from theparameters to the constructor. (Note that the names do not always correspondexactly between the LogRecord constructor parameters and the LogRecordattributes.) These attributes can be used to merge data from the record intothe format string. The following table lists (in alphabetical order) theattribute names, their meanings and the corresponding placeholder in a %-styleformat string.

If you are using {}-formatting (str.format()), you can use{attrname} as the placeholder in the format string. If you are using$-formatting (string.Template), use the form${attrname}. Inboth cases, of course, replaceattrname with the actual attribute nameyou want to use.

In the case of {}-formatting, you can specify formatting flags by placing themafter the attribute name, separated from it with a colon. For example: aplaceholder of{msecs:03d} would format a millisecond value of4 as004. Refer to thestr.format() documentation for full details onthe options available to you.

LoggerAdapter Objects¶

LoggerAdapter instances are used to conveniently pass contextualinformation into logging calls. For a usage example, see the section onadding contextual information to your logging output.

classlogging.LoggerAdapter(logger,extra)¶

Returns an instance ofLoggerAdapter initialized with anunderlyingLogger instance and a dict-like object.

process(msg,kwargs)¶

Modifies the message and/or keyword arguments passed to a logging call inorder to insert contextual information. This implementation takes the objectpassed asextra to the constructor and adds it tokwargs using key‘extra’. The return value is a (msg,kwargs) tuple which has the(possibly modified) versions of the arguments passed in.

In addition to the above,LoggerAdapter supports the followingmethods ofLogger:debug(),info(),warning(),error(),exception(),critical(),log(),isEnabledFor(),getEffectiveLevel(),setLevel() andhasHandlers(). These methods have the same signatures as theircounterparts inLogger, so you can use the two types of instancesinterchangeably.

Thread Safety¶

The logging module is intended to be thread-safe without any special workneeding to be done by its clients. It achieves this though using threadinglocks; there is one lock to serialize access to the module’s shared data, andeach handler also creates a lock to serialize access to its underlying I/O.

If you are implementing asynchronous signal handlers using thesignalmodule, you may not be able to use logging from within such handlers. This isbecause lock implementations in thethreading module are not alwaysre-entrant, and so cannot be invoked from such signal handlers.

Module-Level Functions¶

In addition to the classes described above, there are a number of module-levelfunctions.

logging.getLogger(name=None)¶

Return a logger with the specified name or, if name isNone, return alogger which is the root logger of the hierarchy. If specified, the name istypically a dot-separated hierarchical name like‘a’,‘a.b’ or‘a.b.c.d’.Choice of these names is entirely up to the developer who is using logging.

All calls to this function with a given name return the same logger instance.This means that logger instances never need to be passed between different partsof an application.

logging.getLoggerClass()¶

Return either the standardLogger class, or the last class passed tosetLoggerClass(). This function may be called from within a new classdefinition, to ensure that installing a customizedLogger class willnot undo customizations already applied by other code. For example:

classMyLogger(logging.getLoggerClass()):# ... override behaviour here

logging.getLogRecordFactory()¶

Return a callable which is used to create aLogRecord.

New in version 3.2:This function has been provided, along withsetLogRecordFactory(),to allow developers more control over how theLogRecordrepresenting a logging event is constructed.

SeesetLogRecordFactory() for more information about the how thefactory is called.

logging.debug(msg,*args,**kwargs)¶

Logs a message with levelDEBUG on the root logger. Themsg is themessage format string, and theargs are the arguments which are merged intomsg using the string formatting operator. (Note that this means that you canuse keywords in the format string, together with a single dictionary argument.)

There are three keyword arguments inkwargs which are inspected:exc_infowhich, if it does not evaluate as false, causes exception information to beadded to the logging message. If an exception tuple (in the format returned bysys.exc_info()) or an exception instance is provided, it is used;otherwise,sys.exc_info() is called to get the exception information.

The second optional keyword argument isstack_info, which defaults toFalse. If true, stack information is added to the loggingmessage, including the actual logging call. Note that this is not the samestack information as that displayed through specifyingexc_info: Theformer is stack frames from the bottom of the stack up to the logging callin the current thread, whereas the latter is information about stack frameswhich have been unwound, following an exception, while searching forexception handlers.

You can specifystack_info independently ofexc_info, e.g. to just showhow you got to a certain point in your code, even when no exceptions wereraised. The stack frames are printed following a header line which says:

Stack (most recent call last):

This mimics theTraceback(mostrecentcalllast): which is used whendisplaying exception frames.

The third optional keyword argument isextra which can be used to pass adictionary which is used to populate the __dict__ of the LogRecord created forthe logging event with user-defined attributes. These custom attributes can thenbe used as you like. For example, they could be incorporated into loggedmessages. For example:

FORMAT='%(asctime)-15s%(clientip)s%(user)-8s%(message)s'logging.basicConfig(format=FORMAT)d={'clientip':'192.168.0.1','user':'fbloggs'}logging.warning('Protocol problem:%s','connection reset',extra=d)

would print something like:

2006-02-08 22:20:02,165 192.168.0.1 fbloggs  Protocol problem: connection reset

The keys in the dictionary passed inextra should not clash with the keys usedby the logging system. (See theFormatter documentation for moreinformation on which keys are used by the logging system.)

If you choose to use these attributes in logged messages, you need to exercisesome care. In the above example, for instance, theFormatter has beenset up with a format string which expects ‘clientip’ and ‘user’ in the attributedictionary of the LogRecord. If these are missing, the message will not belogged because a string formatting exception will occur. So in this case, youalways need to pass theextra dictionary with these keys.

While this might be annoying, this feature is intended for use in specializedcircumstances, such as multi-threaded servers where the same code executes inmany contexts, and interesting conditions which arise are dependent on thiscontext (such as remote client IP address and authenticated user name, in theabove example). In such circumstances, it is likely that specializedFormatters would be used with particularHandlers.

Changed in version 3.2:Thestack_info parameter was added.

logging.info(msg,*args,**kwargs)¶

Logs a message with levelINFO on the root logger. The arguments areinterpreted as fordebug().

logging.warning(msg,*args,**kwargs)¶

Logs a message with levelWARNING on the root logger. The argumentsare interpreted as fordebug().

Note

There is an obsolete functionwarn which is functionallyidentical towarning. Aswarn is deprecated, please do not useit - usewarning instead.

logging.error(msg,*args,**kwargs)¶

Logs a message with levelERROR on the root logger. The arguments areinterpreted as fordebug().

logging.critical(msg,*args,**kwargs)¶

Logs a message with levelCRITICAL on the root logger. The argumentsare interpreted as fordebug().

logging.exception(msg,*args,**kwargs)¶

Logs a message with levelERROR on the root logger. The arguments areinterpreted as fordebug(). Exception info is added to the loggingmessage. This function should only be called from an exception handler.

logging.log(level,msg,*args,**kwargs)¶

Logs a message with levellevel on the root logger. The other arguments areinterpreted as fordebug().

Note

The above module-level convenience functions, which delegate to theroot logger, callbasicConfig() to ensure that at least one handleris available. Because of this, they shouldnot be used in threads,in versions of Python earlier than 2.7.1 and 3.2, unless at least onehandler has been added to the root loggerbefore the threads arestarted. In earlier versions of Python, due to a thread safety shortcominginbasicConfig(), this can (under rare circumstances) lead tohandlers being added multiple times to the root logger, which can in turnlead to multiple messages for the same event.

logging.disable(level=CRITICAL)¶

Provides an overriding levellevel for all loggers which takes precedence overthe logger’s own level. When the need arises to temporarily throttle loggingoutput down across the whole application, this function can be useful. Itseffect is to disable all logging calls of severitylevel and below, so thatif you call it with a value of INFO, then all INFO and DEBUG events would bediscarded, whereas those of severity WARNING and above would be processedaccording to the logger’s effective level. Iflogging.disable(logging.NOTSET) is called, it effectively removes thisoverriding level, so that logging output again depends on the effectivelevels of individual loggers.

Note that if you have defined any custom logging level higher thanCRITICAL (this is not recommended), you won’t be able to rely on thedefault value for thelevel parameter, but will have to explicitly supply asuitable value.

Changed in version 3.7:Thelevel parameter was defaulted to levelCRITICAL. Seebpo-28524 for more information about this change.

logging.addLevelName(level,levelName)¶

Associates levellevel with textlevelName in an internal dictionary, which isused to map numeric levels to a textual representation, for example when aFormatter formats a message. This function can also be used to defineyour own levels. The only constraints are that all levels used must beregistered using this function, levels should be positive integers and theyshould increase in increasing order of severity.

Note

If you are thinking of defining your own levels, please see thesection onCustom Levels.

logging.getLevelName(level)¶

Returns the textual or numeric representation of logging levellevel.

Iflevel is one of the predefined levelsCRITICAL,ERROR,WARNING,INFO orDEBUG then you get thecorresponding string. If you have associated levels with names usingaddLevelName() then the name you have associated withlevel isreturned. If a numeric value corresponding to one of the defined levels ispassed in, the corresponding string representation is returned.

Thelevel parameter also accepts a string representation of the level suchas ‘INFO’. In such cases, this functions returns the corresponding numericvalue of the level.

If no matching numeric or string value is passed in, the string‘Level %s’ % level is returned.

Note

Levels are internally integers (as they need to be compared in thelogging logic). This function is used to convert between an integer leveland the level name displayed in the formatted log output by means of the%(levelname)s format specifier (seeLogRecord attributes), andvice versa.

Changed in version 3.4:In Python versions earlier than 3.4, this function could also be passed atext level, and would return the corresponding numeric value of the level.This undocumented behaviour was considered a mistake, and was removed inPython 3.4, but reinstated in 3.4.2 due to retain backward compatibility.

logging.makeLogRecord(attrdict)¶

Creates and returns a newLogRecord instance whose attributes aredefined byattrdict. This function is useful for taking a pickledLogRecord attribute dictionary, sent over a socket, and reconstitutingit as aLogRecord instance at the receiving end.

logging.basicConfig(**kwargs)¶

Does basic configuration for the logging system by creating aStreamHandler with a defaultFormatter and adding it to theroot logger. The functionsdebug(),info(),warning(),error() andcritical() will callbasicConfig() automaticallyif no handlers are defined for the root logger.

This function does nothing if the root logger already has handlersconfigured, unless the keyword argumentforce is set toTrue.

Note

This function should be called from the main threadbefore other threads are started. In versions of Python prior to2.7.1 and 3.2, if this function is called from multiple threads,it is possible (in rare circumstances) that a handler will be addedto the root logger more than once, leading to unexpected resultssuch as messages being duplicated in the log.

The following keyword arguments are supported.

Format	Description
filename	Specifies that a FileHandler be created,using the specified filename, rather than aStreamHandler.
filemode	Iffilename is specified, open the filein thismode. Defaultsto'a'.
format	Use the specified format string for thehandler. Defaults to attributeslevelname,name andmessageseparated by colons.
datefmt	Use the specified date/time format, asaccepted bytime.strftime().
style	Ifformat is specified, use this stylefor the format string. One of'%','{' or'$' forprintf-style,str.format() orstring.Template respectively.Defaults to'%'.
level	Set the root logger level to the specifiedlevel.
stream	Use the specified stream to initialize theStreamHandler. Note that this argument isincompatible withfilename - if bothare present, aValueError is raised.
handlers	If specified, this should be an iterable ofalready created handlers to add to the rootlogger. Any handlers which don’t alreadyhave a formatter set will be assigned thedefault formatter created in this function.Note that this argument is incompatiblewithfilename orstream - if bothare present, aValueError is raised.
force	If this keyword argument is specified astrue, any existing handlers attached to theroot logger are removed and closed, beforecarrying out the configuration as specifiedby the other arguments.

Changed in version 3.2:Thestyle argument was added.

Changed in version 3.3:Thehandlers argument was added. Additional checks were added tocatch situations where incompatible arguments are specified (e.g.handlers together withstream orfilename, orstreamtogether withfilename).

Changed in version 3.8:Theforce argument was added.

logging.shutdown()¶

Informs the logging system to perform an orderly shutdown by flushing andclosing all handlers. This should be called at application exit and nofurther use of the logging system should be made after this call.

When the logging module is imported, it registers this function as an exithandler (seeatexit), so normally there’s no need to do thatmanually.

logging.setLoggerClass(klass)¶

Tells the logging system to use the classklass when instantiating a logger.The class should define__init__() such that only a name argument isrequired, and the__init__() should callLogger.__init__(). Thisfunction is typically called before any loggers are instantiated by applicationswhich need to use custom logger behavior. After this call, as at any othertime, do not instantiate loggers directly using the subclass: continue to usethelogging.getLogger() API to get your loggers.

logging.setLogRecordFactory(factory)¶

Set a callable which is used to create aLogRecord.

Parameters

factory – The factory callable to be used to instantiate a log record.

New in version 3.2:This function has been provided, along withgetLogRecordFactory(), toallow developers more control over how theLogRecord representinga logging event is constructed.

The factory has the following signature:

factory(name,level,fn,lno,msg,args,exc_info,func=None,sinfo=None,**kwargs)

name

The logger name.

level

The logging level (numeric).

fn

The full pathname of the file where the logging call was made.

lno

The line number in the file where the logging call was made.

msg

The logging message.

args

The arguments for the logging message.

exc_info

An exception tuple, orNone.

func

The name of the function or method which invoked the loggingcall.

sinfo

A stack traceback such as is provided bytraceback.print_stack(), showing the call hierarchy.

kwargs

Additional keyword arguments.

Module-Level Attributes¶

logging.lastResort¶

A “handler of last resort” is available through this attribute. Thisis aStreamHandler writing tosys.stderr with a level ofWARNING, and is used to handle logging events in the absence of anylogging configuration. The end result is to just print the message tosys.stderr. This replaces the earlier error message saying that“no handlers could be found for logger XYZ”. If you need the earlierbehaviour for some reason,lastResort can be set toNone.

New in version 3.2.

Integration with the warnings module¶

ThecaptureWarnings() function can be used to integrateloggingwith thewarnings module.

logging.captureWarnings(capture)¶

This function is used to turn the capture of warnings by logging on andoff.

Ifcapture isTrue, warnings issued by thewarnings module willbe redirected to the logging system. Specifically, a warning will beformatted usingwarnings.formatwarning() and the resulting stringlogged to a logger named'py.warnings' with a severity ofWARNING.

Ifcapture isFalse, the redirection of warnings to the logging systemwill stop, and warnings will be redirected to their original destinations(i.e. those in effect beforecaptureWarnings(True) was called).