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. In addition, all loggers are descendants of the rootlogger. The logger name hierarchy is analogous to the Python package hierarchy,and identical to it if you organise your loggers on a per-module basis usingthe recommended constructionlogging.getLogger(__name__). That’s becausein a module,__name__ is the module’s name in the Python package namespace.

classlogging.Logger¶

name¶

This is the logger’s name, and is the value that was passed togetLogger()to obtain the logger.

Note

This attribute should be treated as read-only.

level¶

The threshold of this logger, as set by thesetLevel() method.

Note

Do not set this attribute directly - always usesetLevel(),which has checks for the level passed to it.

parent¶

The parent logger of this logger. It may change based on later instantiationof loggers which are higher up in the namespace hierarchy.

Note

This value should be treated as read-only.

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.

Spelling it out with an example: If the propagate attribute of the logger namedA.B.C evaluates to true, any event logged toA.B.C via a method call such aslogging.getLogger('A.B.C').error(...) will [subject to passing that logger’slevel and filter settings] be passed in turn to any handlers attached to loggersnamedA.B,A and the root logger, after first being passed to any handlersattached toA.B.C. If any logger in the chainA.B.C,A.B,A has itspropagate attribute set to false, then that is the last logger whose handlersare offered the event to handle, and propagation stops at that point.

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.

handlers¶

The list of handlers directly attached to this logger instance.

Note

This attribute should be treated as read-only; it is normally changed viatheaddHandler() andremoveHandler() methods, which use locks to ensurethread-safe operation.

disabled¶

This attribute disables handling of any events. It is set toFalse in theinitializer, and only changed by logging configuration code.

Note

This attribute should be treated as read-only.

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.

Added in version 3.2.

getChildren()¶

Returns a set of loggers which are immediate children of this logger. So forexamplelogging.getLogger().getChildren() might return a set containingloggers namedfoo andbar, but a logger namedfoo.bar wouldn’t beincluded in the set. Likewise,logging.getLogger('foo').getChildren() mightreturn a set including a logger namedfoo.bar, but it wouldn’t include onenamedfoo.bar.baz.

Added in version 3.12.

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)s%(clientip)-15s%(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 the section onLogRecord attributes 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.

If no handler is attached to this logger (or any of its ancestors,taking into account the relevantLogger.propagate attributes),the message will be sent to the handler set onlastResort.

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.

Added 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 the formatter for this handler tofmt.Thefmt argument must be aFormatter instance orNone.

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 outputbut removes the handler from an internal map of handlers, which is usedfor handler lookup by name.

Subclasses should ensure that this gets called from 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.

Warning

This method is called after a handler-level lock is acquired, whichis released after this method returns. When you override this method, notethat you should be careful when calling anything that invokes other parts ofthe logging API which might do locking, because that might result in adeadlock. Specifically:

• Logging configuration APIs acquire the module-level lock, and thenindividual handler-level locks as those handlers are configured.

• Many logging APIs lock the module-level lock. If such an API is calledfrom this method, it could cause a deadlock if a configuration call ismade on another thread, because that thread will try to acquire themodule-level lockbefore the handler-level lock, whereas this threadtries to acquire the module-level lockafter the handler-level lock(because in this method, the handler-level lock has already been acquired).

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

Formatter Objects¶

classlogging.Formatter(fmt=None,datefmt=None,style='%',validate=True,*,defaults=None)¶

Responsible for converting aLogRecord to an output stringto be interpreted by a human or external system.

Parameters:

• fmt (str) – A format string in the givenstyle forthe logged output as a whole.The possible mapping keys are drawn from theLogRecord object’sLogRecord attributes.If not specified,'%(message)s' is used,which is just the logged message.

• datefmt (str) – A format string in the givenstyle forthe date/time portion of the logged output.If not specified, the default described informatTime() is used.

• style (str) – Can be one of'%','{' or'$' and determineshow the format string will be merged with its data: using one ofprintf-style String Formatting (%),str.format() ({)orstring.Template ($). This only applies tofmt anddatefmt (e.g.'%(message)s' versus'{message}'),not to the actual log messages passed to the logging methods.However, there areother waysto use{- and$-formatting for log messages.

• validate (bool) – IfTrue (the default), incorrect or mismatchedfmt andstyle will raise aValueError; for example,logging.Formatter('%(asctime)s-%(message)s',style='{').

• defaults (dict[str,Any]) – A dictionary with default values to use in custom fields.For example,logging.Formatter('%(ip)s%(message)s',defaults={"ip":None})

Changed in version 3.2:Added thestyle parameter.

Changed in version 3.8:Added thevalidate parameter.

Changed in version 3.10:Added thedefaults parameter.

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 (by setting theexc_text attribute toNone) after a formatterhas done its formatting, so that the next formatter to handle the eventdoesn’t use the cached value, but recalculates 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).

Changed in version 3.9:Thedefault_msec_format can beNone.

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.

classlogging.BufferingFormatter(linefmt=None)¶

A base formatter class suitable for subclassing when you want to format anumber of records. You can pass aFormatter instance which you wantto use to format each line (that corresponds to a single record). If notspecified, the default formatter (which just outputs the event message) isused as the line formatter.

formatHeader(records)¶

Return a header for a list ofrecords. The base implementation justreturns the empty string. You will need to override this method if youwant specific behaviour, e.g. to show the count of records, a title or aseparator line.

formatFooter(records)¶

Return a footer for a list ofrecords. The base implementation justreturns the empty string. You will need to override this method if youwant specific behaviour, e.g. to show the count of records or a separatorline.

format(records)¶

Return formatted text for a list ofrecords. The base implementationjust returns the empty string if there are no records; otherwise, itreturns the concatenation of the header, each record formatted with theline formatter, and the footer.

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 false for no, true foryes. Filters can either modify log records in-place or return a completelydifferent record instance which will replace the originallog record in any future processing of the event.

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,which are combined usingmsg%args to createthemessage attribute of the record.

Parameters:

• name (str) – The name of the logger used to log the eventrepresented by thisLogRecord.Note that the logger name in theLogRecordwill always have this value,even though it may be emitted by a handlerattached to a different (ancestor) logger.

• level (int) – Thenumeric level of the logging event(such as10 forDEBUG,20 forINFO, etc).Note that this is converted totwo attributes of the LogRecord:levelno for the numeric valueandlevelname for the corresponding level name.

• pathname (str) – The full string path of the source filewhere the logging call was made.

• lineno (int) – The line number in the source filewhere the logging call was made.

• msg (Any) – The event description message,which can be a %-format string with placeholders for variable data,or an arbitrary object (seeUsing arbitrary objects as messages).

• args (tuple |dict[str,Any]) – Variable data to merge into themsg argumentto obtain the event description.

• exc_info (tuple[type[BaseException],BaseException,types.TracebackType]|None) – An exception tuple with the current exception information,as returned bysys.exc_info(),orNone if no exception information is available.

• func (str |None) – The name of the function or methodfrom which the logging call was invoked.

• sinfo (str |None) – A text string representing stack informationfrom the base of the 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:03.0f} 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,merge_extra=False)¶

Returns an instance ofLoggerAdapter initialized with anunderlyingLogger instance, a dict-like object (extra), and aboolean (merge_extra) indicating whether or not theextra argument ofindividual log calls should be merged with theLoggerAdapter extra.The default behavior is to ignore theextra argument of individual logcalls and only use the one of theLoggerAdapter instance

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.

manager¶

Delegates to the underlyingmanager onlogger.

_log¶

Delegates to the underlying_log() method onlogger.

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.

Changed in version 3.2:TheisEnabledFor(),getEffectiveLevel(),setLevel() andhasHandlers() methods were addedtoLoggerAdapter. These methods delegate to the underlying logger.

Changed in version 3.6:Attributemanager and method_log() were added, whichdelegate to the underlying logger and allow adapters to be nested.

Changed in version 3.13:Themerge_extra argument was added.

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 theroot logger of the hierarchy. If specified, the name is typically adot-separated hierarchical name like‘a’,‘a.b’ or‘a.b.c.d’. Choiceof these names is entirely up to the developer who is using logging, thoughit is recommended that__name__ be used unless you have a specificreason for not doing that, as mentioned inLogger Objects.

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.

Added 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)¶

This is a convenience function that callsLogger.debug(), on the rootlogger. The handling of the arguments is in every way identicalto what is described in that method.

The only difference is that if the root logger has no handlers, thenbasicConfig() is called, prior to callingdebug on the root logger.

For very short scripts or quick demonstrations oflogging facilities,debug and the other module-level functions may be convenient. However,most programs will want to carefully and explicitly control the loggingconfiguration, and should therefore prefer creating a module-level logger andcallingLogger.debug() (or other level-specific methods) on it, asdescribed at the beginnning of this documentation.

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

Logs a message with levelINFO on the root logger. The arguments and behaviorare otherwise the same as fordebug().

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

Logs a message with levelWARNING on the root logger. The arguments and behaviorare otherwise the same 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 and behaviorare otherwise the same as fordebug().

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

Logs a message with levelCRITICAL on the root logger. The arguments and behaviorare otherwise the same as fordebug().

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

Logs a message with levelERROR on the root logger. The arguments and behaviorare otherwise the same 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 arguments and behaviorare otherwise the same as fordebug().

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.getLevelNamesMapping()¶

Returns a mapping from level names to their corresponding logging levels. For example, thestring “CRITICAL” maps toCRITICAL. The returned mapping is copied from an internalmapping on each call to this function.

Added in version 3.11.

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.getHandlerByName(name)¶

Returns a handler with the specifiedname, orNone if there is no handlerwith that name.

Added in version 3.12.

logging.getHandlerNames()¶

Returns an immutable set of all known handler names.

Added in version 3.12.

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 aFileHandler becreated, 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 thisargument is incompatible withfilename -if both are present, aValueError israised.
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.
encoding	If this keyword argument is specified alongwithfilename, its value is used when theFileHandler is created, and thusused when opening the output file.
errors	If this keyword argument is specified alongwithfilename, its value is used when theFileHandler is created, and thusused when opening the output file. If notspecified, the value ‘backslashreplace’ isused. Note that ifNone is specified,it will be passed as such toopen(),which means that it will be treated thesame as passing ‘errors’.

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.

Changed in version 3.9:Theencoding anderrors arguments were 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.

Added 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.

Added in version 3.2.

logging.raiseExceptions¶

Used to see if exceptions during handling should be propagated.

Default:True.

IfraiseExceptions isFalse,exceptions get silently ignored. This is what is mostly wantedfor a logging system - most users will not care about errors inthe logging system, they are more interested in application errors.

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).