12/12/2010 11:46:36 AM is when this event was logged. The format of the datefmt argument is the same as supported by$_{time.strftime()}$ . That concludes the basic tutorial. It should be enough to get you up and running with logging. There’s a lot more that the logging package offers, but to get the best out of it, you’ll need to invest a little more of your time in reading the following sections. If you’re ready for that, grab some of your favourite beverage and carry on. If your logging needs are simple, then use the above examples to incorporate logging into your own scripts, and if you run into problems or don’t understand something, please post a question on the comp.lang.python Usenet group (available at https://groups.google.com/forum/#!forum/comp.lang.python) and you should receive help before too long. Still here? You can carry on reading the next few sections, which provide a slightly more advanced/in-depth tutorial than the basic one above. After that, you can take a look at the logging-cookbook. The logging library takes a modular approach and offers several categories of components: loggers, handlers, filters, and formatters. Log event information is passed between loggers, handlers, filters and formatters in a$_{LogRecord}$ instance. Logging is performed by calling methods on instances of the$_{Logger}$ class (hereafter called loggers ). Each instance has a name, and they are conceptually arranged in a namespace hierarchy using dots (periods) as separators. For example, a logger named ‘scan’ is the parent of loggers ‘scan.text’, ‘scan.html’ and ‘scan.pdf’. Logger names can be anything you want, and indicate the area of an application in which a logged message originates. A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows: This means that logger names track the package/module hierarchy, and it’s intuitively obvious where events are logged just from the logger name. logger=logging.getLogger(__name__ ) The root of the hierarchy of loggers is called the root logger. That’s the logger used by the functions$_{debug()}$ , info() ,$_{warning()}$ ,$_{error()}$ and$_{critical()}$ , which just call the same-named method of the root logger. The functions and the methods have the same signatures. The root logger’s name is printed as ‘root’ in the logged output. It is, of course, possible to log messages to different destinations. Support is included in the package for writing log messages to files, HTTP GET/POST locations, email via SMTP, generic sockets, queues, or OS-specific logging mechanisms such as syslog or the Windows NT event log. Destinations are served by handler classes. You can create your own log destination class if you have special requirements not met by any of the built-in handler classes. By default, no destination is set for any logging messages. You can specify a destination (such as console or file) by using$_{basicConfig()}$ as in the tutorial examples. If you call the functions$_{debug()}$ ,$_{info()}$ ,$_{warning()}$ , error() and$_{critical()}$ , they will check to see if no destination is set; and if one is not set, they will set a destination of the console ($_{sys.stderr}$ ) and a default format for the displayed message before delegating to the root logger to do the actual message output. 6 • Loggers expose the interface that application code directly uses. • Handlers send the log records (created by loggers) to the appropriate destination. • Filters provide a finer grained facility for determining which log records to output. • Formatters specify the layout of log records in the final output. 2 Advanced Logging Tutorial 1.8 Next Steps