Docs for DAL.logger.critical

[ Python Tutorial ] [ Python Libraries ] [ web2py epydoc ]

Description


<type 'instancemethod'>










Log 'msg % args' with severity 'CRITICAL'.

To pass exception information, use the keyword argument exc_info with
a true value, e.g.

logger.critical("Houston, we have a %s", "major disaster", exc_info=1)


Attributes


DAL.logger.critical.__call__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__call__(...) <==> x(...)

DAL.logger.critical.__class__ <type 'type'> extends (<type 'object'>,) belongs to class <type 'type'>
instancemethod(function, instance, class) Create an instance method object.

DAL.logger.critical.__cmp__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__cmp__(y) <==> cmp(x,y)

DAL.logger.critical.__delattr__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__delattr__('name') <==> del x.name

DAL.logger.critical.__doc__ <type 'str'> belongs to class <type 'str'>
str(object='') -> string Return a nice string representation of the object. If the argument is a string, the return value is the same object.

DAL.logger.critical.__format__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
default object formatter

DAL.logger.critical.__func__ <type 'function'> belongs to class <type 'function'>
Log 'msg % args' with severity 'CRITICAL'. To pass exception information, use the keyword argument exc_info with a true value, e.g. logger.critical("Houston, we have a %s", "major disaster", exc_info=1)

DAL.logger.critical.__get__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
descr.__get__(obj[, type]) -> value

DAL.logger.critical.__getattribute__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__getattribute__('name') <==> x.name

DAL.logger.critical.__hash__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__hash__() <==> hash(x)

DAL.logger.critical.__init__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__init__(...) initializes x; see help(type(x)) for signature

DAL.logger.critical.__new__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
T.__new__(S, ...) -> a new object with type S, a subtype of T

DAL.logger.critical.__reduce__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
helper for pickle

DAL.logger.critical.__reduce_ex__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
helper for pickle

DAL.logger.critical.__repr__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__repr__() <==> repr(x)

DAL.logger.critical.__self__ <class 'logging.Logger'> belongs to class <class 'logging.Logger'>
Instances of the Logger class represent a single logging channel. A "logging channel" indicates an area of an application. Exactly how an "area" is defined is up to the application developer. Since an application can have any number of areas, logging channels are identified by a unique string. Application areas can be nested (e.g. an area of "input processing" might include sub-areas "read CSV files", "read XLS files" and "read Gnumeric files"). To cater for this natural nesting, channel names are organized into a namespace hierarchy where levels are separated by periods, much like the Java or Python package namespace. So in the instance given above, channel names might be "input" for the upper level, and "input.csv", "input.xls" and "input.gnu" for the sub-levels. There is no arbitrary limit to the depth of nesting.

DAL.logger.critical.__setattr__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__setattr__('name', value) <==> x.name = value

DAL.logger.critical.__sizeof__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
__sizeof__() -> int size of object in memory, in bytes

DAL.logger.critical.__str__ <type 'method-wrapper'> belongs to class <type 'method-wrapper'>
x.__str__() <==> str(x)

DAL.logger.critical.__subclasshook__ <type 'builtin_function_or_method'> belongs to class <type 'builtin_function_or_method'>
Abstract classes can override this to customize issubclass(). This is invoked early on by abc.ABCMeta.__subclasscheck__(). It should return True, False or NotImplemented. If it returns NotImplemented, the normal algorithm is used. Otherwise, it overrides the normal algorithm (and the outcome is cached).

DAL.logger.critical.im_class <type 'type'> extends (<class 'logging.Filterer'>,) belongs to class <type 'type'>
Instances of the Logger class represent a single logging channel. A "logging channel" indicates an area of an application. Exactly how an "area" is defined is up to the application developer. Since an application can have any number of areas, logging channels are identified by a unique string. Application areas can be nested (e.g. an area of "input processing" might include sub-areas "read CSV files", "read XLS files" and "read Gnumeric files"). To cater for this natural nesting, channel names are organized into a namespace hierarchy where levels are separated by periods, much like the Java or Python package namespace. So in the instance given above, channel names might be "input" for the upper level, and "input.csv", "input.xls" and "input.gnu" for the sub-levels. There is no arbitrary limit to the depth of nesting.

DAL.logger.critical.im_func <type 'function'> belongs to class <type 'function'>
Log 'msg % args' with severity 'CRITICAL'. To pass exception information, use the keyword argument exc_info with a true value, e.g. logger.critical("Houston, we have a %s", "major disaster", exc_info=1)

DAL.logger.critical.im_self <class 'logging.Logger'> belongs to class <class 'logging.Logger'>
Instances of the Logger class represent a single logging channel. A "logging channel" indicates an area of an application. Exactly how an "area" is defined is up to the application developer. Since an application can have any number of areas, logging channels are identified by a unique string. Application areas can be nested (e.g. an area of "input processing" might include sub-areas "read CSV files", "read XLS files" and "read Gnumeric files"). To cater for this natural nesting, channel names are organized into a namespace hierarchy where levels are separated by periods, much like the Java or Python package namespace. So in the instance given above, channel names might be "input" for the upper level, and "input.csv", "input.xls" and "input.gnu" for the sub-levels. There is no arbitrary limit to the depth of nesting.