# Python Documentation Turkish Translation

# Copyright (C) 2001-2022, Python Software Foundation

# This file is distributed under the same license as the Python package.

#

#, fuzzy

msgid ""

msgstr ""

"Project-Id-Version: Python 3.11\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2022-12-17 01:28+0300\n"

"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"

"Last-Translator: \n"

"Language-Team: TURKISH <python.docs.tr@gmail.com>\n"

"Language: tr\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

#: howto/logging.rst:3

msgid "Logging HOWTO"

msgstr ""

#: howto/logging.rst:0

msgid "Author"

msgstr ""

#: howto/logging.rst:5

msgid "Vinay Sajip <vinay_sajip at red-dove dot com>"

msgstr ""

#: howto/logging.rst:12

msgid "Basic Logging Tutorial"

msgstr ""

#: howto/logging.rst:14

msgid ""

"Logging is a means of tracking events that happen when some software runs. "

"The software's developer adds logging calls to their code to indicate that "

"certain events have occurred. An event is described by a descriptive message "

"which can optionally contain variable data (i.e. data that is potentially "

"different for each occurrence of the event). Events also have an importance "

"which the developer ascribes to the event; the importance can also be called "

"the *level* or *severity*."

msgstr ""

#: howto/logging.rst:23

msgid "When to use logging"

msgstr ""

#: howto/logging.rst:25

msgid ""

"Logging provides a set of convenience functions for simple logging usage. "

"These are :func:`debug`, :func:`info`, :func:`warning`, :func:`error` and :"

"func:`critical`. To determine when to use logging, see the table below, "

"which states, for each of a set of common tasks, the best tool to use for it."

msgstr ""

#: howto/logging.rst:31

msgid "Task you want to perform"

msgstr ""

#: howto/logging.rst:31

msgid "The best tool for the task"

msgstr ""

#: howto/logging.rst:33

msgid ""

"Display console output for ordinary usage of a command line script or program"

msgstr ""

#: howto/logging.rst:33

msgid ":func:`print`"

msgstr ""

#: howto/logging.rst:37

msgid ""

"Report events that occur during normal operation of a program (e.g. for "

"status monitoring or fault investigation)"

msgstr ""

#: howto/logging.rst:37

msgid ""

":func:`logging.info` (or :func:`logging.debug` for very detailed output for "

"diagnostic purposes)"

msgstr ""

#: howto/logging.rst:42

msgid "Issue a warning regarding a particular runtime event"

msgstr ""

#: howto/logging.rst:42

msgid ""

":func:`warnings.warn` in library code if the issue is avoidable and the "

"client application should be modified to eliminate the warning"

msgstr ""

#: howto/logging.rst:47

msgid ""

":func:`logging.warning` if there is nothing the client application can do "

"about the situation, but the event should still be noted"

msgstr ""

#: howto/logging.rst:52

msgid "Report an error regarding a particular runtime event"

msgstr ""

#: howto/logging.rst:52

msgid "Raise an exception"

msgstr ""

#: howto/logging.rst:55

msgid ""

"Report suppression of an error without raising an exception (e.g. error "

"handler in a long-running server process)"

msgstr ""

#: howto/logging.rst:55

msgid ""

":func:`logging.error`, :func:`logging.exception` or :func:`logging.critical` "

"as appropriate for the specific error and application domain"

msgstr ""

#: howto/logging.rst:62

msgid ""

"The logging functions are named after the level or severity of the events "

"they are used to track. The standard levels and their applicability are "

"described below (in increasing order of severity):"

msgstr ""

#: howto/logging.rst:862

msgid "Level"

msgstr ""

#: howto/logging.rst:69

msgid "When it's used"

msgstr ""

#: howto/logging.rst:872

msgid "``DEBUG``"

msgstr ""

#: howto/logging.rst:71

msgid ""

"Detailed information, typically of interest only when diagnosing problems."

msgstr ""

#: howto/logging.rst:870

msgid "``INFO``"

msgstr ""

#: howto/logging.rst:74

msgid "Confirmation that things are working as expected."

msgstr ""

#: howto/logging.rst:868

msgid "``WARNING``"

msgstr ""

#: howto/logging.rst:77

msgid ""

"An indication that something unexpected happened, or indicative of some "

"problem in the near future (e.g. 'disk space low'). The software is still "

"working as expected."

msgstr ""

#: howto/logging.rst:866

msgid "``ERROR``"

msgstr ""

#: howto/logging.rst:82

msgid ""

"Due to a more serious problem, the software has not been able to perform "

"some function."

msgstr ""

#: howto/logging.rst:864

msgid "``CRITICAL``"

msgstr ""

#: howto/logging.rst:85

msgid ""

"A serious error, indicating that the program itself may be unable to "

"continue running."

msgstr ""

#: howto/logging.rst:89

msgid ""

"The default level is ``WARNING``, which means that only events of this level "

"and above will be tracked, unless the logging package is configured to do "

"otherwise."

msgstr ""

#: howto/logging.rst:93

msgid ""

"Events that are tracked can be handled in different ways. The simplest way "

"of handling tracked events is to print them to the console. Another common "

"way is to write them to a disk file."

msgstr ""

#: howto/logging.rst:101

msgid "A simple example"

msgstr ""

#: howto/logging.rst:103

msgid "A very simple example is::"

msgstr ""

#: howto/logging.rst:109

msgid "If you type these lines into a script and run it, you'll see:"

msgstr ""

#: howto/logging.rst:115

msgid ""

"printed out on the console. The ``INFO`` message doesn't appear because the "

"default level is ``WARNING``. The printed message includes the indication of "

"the level and the description of the event provided in the logging call, i."

"e. 'Watch out!'. Don't worry about the 'root' part for now: it will be "

"explained later. The actual output can be formatted quite flexibly if you "

"need that; formatting options will also be explained later."

msgstr ""

#: howto/logging.rst:124

msgid "Logging to a file"

msgstr ""

#: howto/logging.rst:126

msgid ""

"A very common situation is that of recording logging events in a file, so "

"let's look at that next. Be sure to try the following in a newly started "

"Python interpreter, and don't just continue from the session described "

"above::"

msgstr ""

#: howto/logging.rst:137

msgid ""

"The *encoding* argument was added. In earlier Python versions, or if not "

"specified, the encoding used is the default value used by :func:`open`. "

"While not shown in the above example, an *errors* argument can also now be "

"passed, which determines how encoding errors are handled. For available "

"values and the default, see the documentation for :func:`open`."

msgstr ""

#: howto/logging.rst:144

msgid ""

"And now if we open the file and look at what we have, we should find the log "

"messages:"

msgstr ""

#: howto/logging.rst:154

msgid ""

"This example also shows how you can set the logging level which acts as the "

"threshold for tracking. In this case, because we set the threshold to "

"``DEBUG``, all of the messages were printed."

msgstr ""

#: howto/logging.rst:158

msgid ""

"If you want to set the logging level from a command-line option such as:"

msgstr ""

#: howto/logging.rst:164

msgid ""

"and you have the value of the parameter passed for ``--log`` in some "

"variable *loglevel*, you can use::"

msgstr ""

#: howto/logging.rst:169

msgid ""

"to get the value which you'll pass to :func:`basicConfig` via the *level* "

"argument. You may want to error check any user input value, perhaps as in "

"the following example::"

msgstr ""

#: howto/logging.rst:181

msgid ""

"The call to :func:`basicConfig` should come *before* any calls to :func:"

"`debug`, :func:`info`, etc. Otherwise, those functions will call :func:"

"`basicConfig` for you with the default options. As it's intended as a one-"

"off simple configuration facility, only the first call will actually do "

"anything: subsequent calls are effectively no-ops."

msgstr ""

#: howto/logging.rst:187

msgid ""

"If you run the above script several times, the messages from successive runs "

"are appended to the file *example.log*. If you want each run to start "

"afresh, not remembering the messages from earlier runs, you can specify the "

"*filemode* argument, by changing the call in the above example to::"

msgstr ""

#: howto/logging.rst:194

msgid ""

"The output will be the same as before, but the log file is no longer "

"appended to, so the messages from earlier runs are lost."

msgstr ""

#: howto/logging.rst:199

msgid "Logging from multiple modules"

msgstr ""

#: howto/logging.rst:201

msgid ""

"If your program consists of multiple modules, here's an example of how you "

"could organize logging in it::"

msgstr ""

#: howto/logging.rst:225

msgid "If you run *myapp.py*, you should see this in *myapp.log*:"

msgstr ""

#: howto/logging.rst:233

msgid ""

"which is hopefully what you were expecting to see. You can generalize this "

"to multiple modules, using the pattern in *mylib.py*. Note that for this "

"simple usage pattern, you won't know, by looking in the log file, *where* in "

"your application your messages came from, apart from looking at the event "

"description. If you want to track the location of your messages, you'll need "

"to refer to the documentation beyond the tutorial level -- see :ref:`logging-"

"advanced-tutorial`."

msgstr ""

#: howto/logging.rst:243

msgid "Logging variable data"

msgstr ""

#: howto/logging.rst:245

msgid ""

"To log variable data, use a format string for the event description message "

"and append the variable data as arguments. For example::"

msgstr ""

#: howto/logging.rst:251

msgid "will display:"

msgstr ""

#: howto/logging.rst:257

msgid ""

"As you can see, merging of variable data into the event description message "

"uses the old, %-style of string formatting. This is for backwards "

"compatibility: the logging package pre-dates newer formatting options such "

"as :meth:`str.format` and :class:`string.Template`. These newer formatting "

"options *are* supported, but exploring them is outside the scope of this "

"tutorial: see :ref:`formatting-styles` for more information."

msgstr ""

#: howto/logging.rst:266

msgid "Changing the format of displayed messages"

msgstr ""

#: howto/logging.rst:268

msgid ""

"To change the format which is used to display messages, you need to specify "

"the format you want to use::"

msgstr ""

#: howto/logging.rst:277

msgid "which would print:"

msgstr ""

#: howto/logging.rst:285

msgid ""

"Notice that the 'root' which appeared in earlier examples has disappeared. "

"For a full set of things that can appear in format strings, you can refer to "

"the documentation for :ref:`logrecord-attributes`, but for simple usage, you "

"just need the *levelname* (severity), *message* (event description, "

"including variable data) and perhaps to display when the event occurred. "

"This is described in the next section."

msgstr ""

#: howto/logging.rst:294

msgid "Displaying the date/time in messages"

msgstr ""

#: howto/logging.rst:296

msgid ""

"To display the date and time of an event, you would place '%(asctime)s' in "

"your format string::"

msgstr ""

#: howto/logging.rst:303

msgid "which should print something like this:"

msgstr ""

#: howto/logging.rst:309

msgid ""

"The default format for date/time display (shown above) is like ISO8601 or :"

"rfc:`3339`. If you need more control over the formatting of the date/time, "

"provide a *datefmt* argument to ``basicConfig``, as in this example::"

msgstr ""

#: howto/logging.rst:317

msgid "which would display something like this:"

msgstr ""

#: howto/logging.rst:323

msgid ""

"The format of the *datefmt* argument is the same as supported by :func:`time."

"strftime`."

msgstr ""

#: howto/logging.rst:328

msgid "Next Steps"

msgstr ""

#: howto/logging.rst:330

msgid ""

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

msgstr ""

#: howto/logging.rst:336

msgid ""

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

msgstr ""

#: howto/logging.rst:342

msgid ""

"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 :ref:`logging-cookbook`."

msgstr ""

#: howto/logging.rst:350

msgid "Advanced Logging Tutorial"

msgstr ""

#: howto/logging.rst:352

msgid ""

"The logging library takes a modular approach and offers several categories "

"of components: loggers, handlers, filters, and formatters."

msgstr ""

#: howto/logging.rst:355

msgid "Loggers expose the interface that application code directly uses."

msgstr ""

#: howto/logging.rst:356

msgid ""

"Handlers send the log records (created by loggers) to the appropriate "

"destination."

msgstr ""

#: howto/logging.rst:358

msgid ""

"Filters provide a finer grained facility for determining which log records "

"to output."

msgstr ""

#: howto/logging.rst:360

msgid "Formatters specify the layout of log records in the final output."

msgstr ""

#: howto/logging.rst:362

msgid ""

"Log event information is passed between loggers, handlers, filters and "

"formatters in a :class:`LogRecord` instance."

msgstr ""

#: howto/logging.rst:365

msgid ""

"Logging is performed by calling methods on instances of the :class:`Logger` "

"class (hereafter called :dfn:`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."

msgstr ""

#: howto/logging.rst:372

msgid ""

"A good convention to use when naming loggers is to use a module-level "

"logger, in each module which uses logging, named as follows::"

msgstr ""

#: howto/logging.rst:377

msgid ""

"This means that logger names track the package/module hierarchy, and it's "

"intuitively obvious where events are logged just from the logger name."

msgstr ""

#: howto/logging.rst:380

msgid ""

"The root of the hierarchy of loggers is called the root logger. That's the "

"logger used by the functions :func:`debug`, :func:`info`, :func:`warning`, :"

"func:`error` and :func:`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."

msgstr ""

#: howto/logging.rst:386

msgid ""

"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 :dfn:`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."

msgstr ""

#: howto/logging.rst:393

msgid ""

"By default, no destination is set for any logging messages. You can specify "

"a destination (such as console or file) by using :func:`basicConfig` as in "

"the tutorial examples. If you call the functions :func:`debug`, :func:"

"`info`, :func:`warning`, :func:`error` and :func:`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."

msgstr ""

#: howto/logging.rst:401

msgid "The default format set by :func:`basicConfig` for messages is:"

msgstr ""

#: howto/logging.rst:407

msgid ""

"You can change this by passing a format string to :func:`basicConfig` with "

"the *format* keyword argument. For all options regarding how a format string "

"is constructed, see :ref:`formatter-objects`."

msgstr ""

#: howto/logging.rst:412

msgid "Logging Flow"

msgstr ""

#: howto/logging.rst:414

msgid ""

"The flow of log event information in loggers and handlers is illustrated in "

"the following diagram."

msgstr ""

#: howto/logging.rst:420

msgid "Loggers"

msgstr ""

#: howto/logging.rst:422

msgid ""

":class:`Logger` objects have a threefold job. First, they expose several "

"methods to application code so that applications can log messages at "

"runtime. Second, logger objects determine which log messages to act upon "

"based upon severity (the default filtering facility) or filter objects. "

"Third, logger objects pass along relevant log messages to all interested log "

"handlers."

msgstr ""

#: howto/logging.rst:428

msgid ""

"The most widely used methods on logger objects fall into two categories: "

"configuration and message sending."

msgstr ""

#: howto/logging.rst:431

msgid "These are the most common configuration methods:"

msgstr ""

#: howto/logging.rst:433

msgid ""

":meth:`Logger.setLevel` specifies the lowest-severity log message a logger "

"will handle, where debug is the lowest built-in severity level and critical "

"is the highest built-in severity. For example, if the severity level is "

"INFO, the logger will handle only INFO, WARNING, ERROR, and CRITICAL "

"messages and will ignore DEBUG messages."

msgstr ""

#: howto/logging.rst:439

msgid ""

":meth:`Logger.addHandler` and :meth:`Logger.removeHandler` add and remove "

"handler objects from the logger object. Handlers are covered in more detail "

"in :ref:`handler-basic`."

msgstr ""

#: howto/logging.rst:443

msgid ""

":meth:`Logger.addFilter` and :meth:`Logger.removeFilter` add and remove "

"filter objects from the logger object. Filters are covered in more detail "

"in :ref:`filter`."

msgstr ""

#: howto/logging.rst:447

msgid ""

"You don't need to always call these methods on every logger you create. See "

"the last two paragraphs in this section."

msgstr ""

#: howto/logging.rst:450

msgid ""

"With the logger object configured, the following methods create log messages:"

msgstr ""

#: howto/logging.rst:452

msgid ""

":meth:`Logger.debug`, :meth:`Logger.info`, :meth:`Logger.warning`, :meth:"

"`Logger.error`, and :meth:`Logger.critical` all create log records with a "

"message and a level that corresponds to their respective method names. The "

"message is actually a format string, which may contain the standard string "

"substitution syntax of ``%s``, ``%d``, ``%f``, and so on. The rest of their "

"arguments is a list of objects that correspond with the substitution fields "

"in the message. With regard to ``**kwargs``, the logging methods care only "

"about a keyword of ``exc_info`` and use it to determine whether to log "

"exception information."

msgstr ""

#: howto/logging.rst:462

msgid ""

":meth:`Logger.exception` creates a log message similar to :meth:`Logger."

"error`. The difference is that :meth:`Logger.exception` dumps a stack trace "

"along with it. Call this method only from an exception handler."

msgstr ""

#: howto/logging.rst:466

msgid ""

":meth:`Logger.log` takes a log level as an explicit argument. This is a "

"little more verbose for logging messages than using the log level "

"convenience methods listed above, but this is how to log at custom log "

"levels."

msgstr ""

#: howto/logging.rst:470

msgid ""

":func:`getLogger` returns a reference to a logger instance with the "

"specified name if it is provided, or ``root`` if not. The names are period-"

"separated hierarchical structures. Multiple calls to :func:`getLogger` with "

"the same name will return a reference to the same logger object. Loggers "

"that are further down in the hierarchical list are children of loggers "

"higher up in the list. For example, given a logger with a name of ``foo``, "

"loggers with names of ``foo.bar``, ``foo.bar.baz``, and ``foo.bam`` are all "

"descendants of ``foo``."

msgstr ""

#: howto/logging.rst:478

msgid ""

"Loggers have a concept of *effective level*. If a level is not explicitly "

"set on a logger, the level of its parent is used instead as its effective "

"level. If the parent has no explicit level set, *its* parent is examined, "

"and so on - all ancestors are searched until an explicitly set level is "

"found. The root logger always has an explicit level set (``WARNING`` by "

"default). When deciding whether to process an event, the effective level of "

"the logger is used to determine whether the event is passed to the logger's "

"handlers."

msgstr ""

#: howto/logging.rst:486

msgid ""

"Child loggers propagate messages up to the handlers associated with their "

"ancestor loggers. Because of this, it is unnecessary to define and configure "

"handlers for all the loggers an application uses. It is sufficient to "

"configure handlers for a top-level logger and create child loggers as "

"needed. (You can, however, turn off propagation by setting the *propagate* "

"attribute of a logger to ``False``.)"

msgstr ""

#: howto/logging.rst:497

msgid "Handlers"

msgstr ""

#: howto/logging.rst:499

msgid ""

":class:`~logging.Handler` objects are responsible for dispatching the "

"appropriate log messages (based on the log messages' severity) to the "

"handler's specified destination. :class:`Logger` objects can add zero or "

"more handler objects to themselves with an :meth:`~Logger.addHandler` "

"method. As an example scenario, an application may want to send all log "

"messages to a log file, all log messages of error or higher to stdout, and "

"all messages of critical to an email address. This scenario requires three "

"individual handlers where each handler is responsible for sending messages "

"of a specific severity to a specific location."

msgstr ""

#: howto/logging.rst:509

msgid ""

"The standard library includes quite a few handler types (see :ref:`useful-"

"handlers`); the tutorials use mainly :class:`StreamHandler` and :class:"

"`FileHandler` in its examples."

msgstr ""

#: howto/logging.rst:513

msgid ""

"There are very few methods in a handler for application developers to "

"concern themselves with. The only handler methods that seem relevant for "

"application developers who are using the built-in handler objects (that is, "

"not creating custom handlers) are the following configuration methods:"

msgstr ""

#: howto/logging.rst:518

msgid ""

"The :meth:`~Handler.setLevel` method, just as in logger objects, specifies "

"the lowest severity that will be dispatched to the appropriate destination. "

"Why are there two :func:`setLevel` methods? The level set in the logger "

"determines which severity of messages it will pass to its handlers. The "

"level set in each handler determines which messages that handler will send "

"on."

msgstr ""

#: howto/logging.rst:524

msgid ""

":meth:`~Handler.setFormatter` selects a Formatter object for this handler to "

"use."

msgstr ""

#: howto/logging.rst:527

msgid ""

":meth:`~Handler.addFilter` and :meth:`~Handler.removeFilter` respectively "

"configure and deconfigure filter objects on handlers."

msgstr ""

#: howto/logging.rst:530

msgid ""

"Application code should not directly instantiate and use instances of :class:"

"`Handler`. Instead, the :class:`Handler` class is a base class that defines "

"the interface that all handlers should have and establishes some default "

"behavior that child classes can use (or override)."

msgstr ""

#: howto/logging.rst:537

msgid "Formatters"

msgstr ""

#: howto/logging.rst:539

msgid ""

"Formatter objects configure the final order, structure, and contents of the "

"log message. Unlike the base :class:`logging.Handler` class, application "

"code may instantiate formatter classes, although you could likely subclass "

"the formatter if your application needs special behavior. The constructor "

"takes three optional arguments -- a message format string, a date format "

"string and a style indicator."

msgstr ""

#: howto/logging.rst:548

msgid ""

"If there is no message format string, the default is to use the raw "

"message. If there is no date format string, the default date format is:"

msgstr ""

#: howto/logging.rst:555

msgid ""

"with the milliseconds tacked on at the end. The ``style`` is one of ``'%'``, "

"``'{'``, or ``'$'``. If one of these is not specified, then ``'%'`` will be "

"used."

msgstr ""

#: howto/logging.rst:558

msgid ""

"If the ``style`` is ``'%'``, the message format string uses ``%(<dictionary "

"key>)s`` styled string substitution; the possible keys are documented in :"

"ref:`logrecord-attributes`. If the style is ``'{'``, the message format "

"string is assumed to be compatible with :meth:`str.format` (using keyword "

"arguments), while if the style is ``'$'`` then the message format string "

"should conform to what is expected by :meth:`string.Template.substitute`."

msgstr ""

#: howto/logging.rst:565

msgid "Added the ``style`` parameter."

msgstr ""

#: howto/logging.rst:568

msgid ""

"The following message format string will log the time in a human-readable "

"format, the severity of the message, and the contents of the message, in "

"that order::"

msgstr ""

#: howto/logging.rst:574

msgid ""

"Formatters use a user-configurable function to convert the creation time of "

"a record to a tuple. By default, :func:`time.localtime` is used; to change "

"this for a particular formatter instance, set the ``converter`` attribute of "

"the instance to a function with the same signature as :func:`time.localtime` "

"or :func:`time.gmtime`. To change it for all formatters, for example if you "

"want all logging times to be shown in GMT, set the ``converter`` attribute "

"in the Formatter class (to ``time.gmtime`` for GMT display)."

msgstr ""

#: howto/logging.rst:584

msgid "Configuring Logging"

msgstr ""

#: howto/logging.rst:588

msgid "Programmers can configure logging in three ways:"

msgstr ""

#: howto/logging.rst:590

msgid ""

"Creating loggers, handlers, and formatters explicitly using Python code that "

"calls the configuration methods listed above."

msgstr ""

#: howto/logging.rst:592

msgid ""

"Creating a logging config file and reading it using the :func:`fileConfig` "

"function."

msgstr ""

#: howto/logging.rst:594

msgid ""

"Creating a dictionary of configuration information and passing it to the :"

"func:`dictConfig` function."

msgstr ""

#: howto/logging.rst:597

msgid ""

"For the reference documentation on the last two options, see :ref:`logging-"

"config-api`. The following example configures a very simple logger, a "

"console handler, and a simple formatter using Python code::"

msgstr ""

#: howto/logging.rst:627

msgid ""

"Running this module from the command line produces the following output:"

msgstr ""

#: howto/logging.rst:638

msgid ""

"The following Python module creates a logger, handler, and formatter nearly "

"identical to those in the example listed above, with the only difference "

"being the names of the objects::"

msgstr ""

#: howto/logging.rst:657

msgid "Here is the logging.conf file:"

msgstr ""

#: howto/logging.rst:689

msgid ""

"The output is nearly identical to that of the non-config-file-based example:"

msgstr ""

#: howto/logging.rst:700

msgid ""

"You can see that the config file approach has a few advantages over the "

"Python code approach, mainly separation of configuration and code and the "

"ability of noncoders to easily modify the logging properties."

msgstr ""

#: howto/logging.rst:704

msgid ""

"The :func:`fileConfig` function takes a default parameter, "

"``disable_existing_loggers``, which defaults to ``True`` for reasons of "

"backward compatibility. This may or may not be what you want, since it will "

"cause any non-root loggers existing before the :func:`fileConfig` call to be "

"disabled unless they (or an ancestor) are explicitly named in the "

"configuration. Please refer to the reference documentation for more "

"information, and specify ``False`` for this parameter if you wish."

msgstr ""

#: howto/logging.rst:712

msgid ""

"The dictionary passed to :func:`dictConfig` can also specify a Boolean value "

"with key ``disable_existing_loggers``, which if not specified explicitly in "

"the dictionary also defaults to being interpreted as ``True``. This leads to "

"the logger-disabling behaviour described above, which may not be what you "

"want - in which case, provide the key explicitly with a value of ``False``."

msgstr ""

#: howto/logging.rst:722

msgid ""

"Note that the class names referenced in config files need to be either "

"relative to the logging module, or absolute values which can be resolved "

"using normal import mechanisms. Thus, you could use either :class:`~logging."

"handlers.WatchedFileHandler` (relative to the logging module) or ``mypackage."

"mymodule.MyHandler`` (for a class defined in package ``mypackage`` and "

"module ``mymodule``, where ``mypackage`` is available on the Python import "

"path)."

msgstr ""

#: howto/logging.rst:730

msgid ""

"In Python 3.2, a new means of configuring logging has been introduced, using "

"dictionaries to hold configuration information. This provides a superset of "

"the functionality of the config-file-based approach outlined above, and is "

"the recommended configuration method for new applications and deployments. "

"Because a Python dictionary is used to hold configuration information, and "

"since you can populate that dictionary using different means, you have more "

"options for configuration. For example, you can use a configuration file in "

"JSON format, or, if you have access to YAML processing functionality, a file "

"in YAML format, to populate the configuration dictionary. Or, of course, you "

"can construct the dictionary in Python code, receive it in pickled form over "

"a socket, or use whatever approach makes sense for your application."

msgstr ""

#: howto/logging.rst:742

msgid ""

"Here's an example of the same configuration as above, in YAML format for the "

"new dictionary-based approach:"

msgstr ""

#: howto/logging.rst:766

msgid ""

"For more information about logging using a dictionary, see :ref:`logging-"

"config-api`."

msgstr ""

#: howto/logging.rst:770

msgid "What happens if no configuration is provided"

msgstr ""

#: howto/logging.rst:772

msgid ""

"If no logging configuration is provided, it is possible to have a situation "

"where a logging event needs to be output, but no handlers can be found to "

"output the event. The behaviour of the logging package in these "

"circumstances is dependent on the Python version."

msgstr ""

#: howto/logging.rst:777

msgid "For versions of Python prior to 3.2, the behaviour is as follows:"

msgstr ""

#: howto/logging.rst:779

msgid ""

"If *logging.raiseExceptions* is ``False`` (production mode), the event is "

"silently dropped."

msgstr ""

#: howto/logging.rst:782

msgid ""

"If *logging.raiseExceptions* is ``True`` (development mode), a message 'No "

"handlers could be found for logger X.Y.Z' is printed once."

msgstr ""

#: howto/logging.rst:785

msgid "In Python 3.2 and later, the behaviour is as follows:"

msgstr ""

#: howto/logging.rst:787

msgid ""

"The event is output using a 'handler of last resort', stored in ``logging."

"lastResort``. This internal handler is not associated with any logger, and "

"acts like a :class:`~logging.StreamHandler` which writes the event "

"description message to the current value of ``sys.stderr`` (therefore "

"respecting any redirections which may be in effect). No formatting is done "

"on the message - just the bare event description message is printed. The "

"handler's level is set to ``WARNING``, so all events at this and greater "

"severities will be output."

msgstr ""

#: howto/logging.rst:796

msgid ""

"To obtain the pre-3.2 behaviour, ``logging.lastResort`` can be set to "

"``None``."

msgstr ""

#: howto/logging.rst:801

msgid "Configuring Logging for a Library"

msgstr ""

#: howto/logging.rst:803

msgid ""

"When developing a library which uses logging, you should take care to "

"document how the library uses logging - for example, the names of loggers "

"used. Some consideration also needs to be given to its logging "

"configuration. If the using application does not use logging, and library "

"code makes logging calls, then (as described in the previous section) events "

"of severity ``WARNING`` and greater will be printed to ``sys.stderr``. This "

"is regarded as the best default behaviour."

msgstr ""

#: howto/logging.rst:811

msgid ""

"If for some reason you *don't* want these messages printed in the absence of "

"any logging configuration, you can attach a do-nothing handler to the top-"

"level logger for your library. This avoids the message being printed, since "

"a handler will always be found for the library's events: it just doesn't "

"produce any output. If the library user configures logging for application "

"use, presumably that configuration will add some handlers, and if levels are "

"suitably configured then logging calls made in library code will send output "

"to those handlers, as normal."

msgstr ""

#: howto/logging.rst:820

msgid ""

"A do-nothing handler is included in the logging package: :class:`~logging."

"NullHandler` (since Python 3.1). An instance of this handler could be added "

"to the top-level logger of the logging namespace used by the library (*if* "

"you want to prevent your library's logged events being output to ``sys."

"stderr`` in the absence of logging configuration). If all logging by a "

"library *foo* is done using loggers with names matching 'foo.x', 'foo.x.y', "

"etc. then the code::"

msgstr ""

#: howto/logging.rst:831

msgid ""

"should have the desired effect. If an organisation produces a number of "

"libraries, then the logger name specified can be 'orgname.foo' rather than "

"just 'foo'."

msgstr ""

#: howto/logging.rst:835

msgid ""

"It is strongly advised that you *do not log to the root logger* in your "

"library. Instead, use a logger with a unique and easily identifiable name, "