python-docs-fr/library/logging.config.po

# Copyright (C) 2001-2018, Python Software Foundation
# For licence information, see README file.
#
msgid ""
msgstr ""
"Project-Id-Version: Python 3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2023-02-12 11:56+0100\n"
"PO-Revision-Date: 2023-03-30 22:50+0200\n"
"Last-Translator: Mathieu Dupuy\n"
"Language-Team: FRENCH <traductions@lists.afpy.org>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 3.2.2\n"

#: library/logging.config.rst:2
msgid ":mod:`logging.config` --- Logging configuration"
msgstr ""

#: library/logging.config.rst:10
msgid "**Source code:** :source:`Lib/logging/config.py`"
msgstr ""

#: library/logging.config.rst:14
msgid ""
"This page contains only reference information. For tutorials, please see"
msgstr ""
"Cette page contient uniquement des informations de référence. Pour des "
"tutoriels, veuillez consulter"

#: library/logging.config.rst:17
msgid ":ref:`Basic Tutorial <logging-basic-tutorial>`"
msgstr ":ref:`Tutoriel basique <logging-basic-tutorial>`"

#: library/logging.config.rst:18
msgid ":ref:`Advanced Tutorial <logging-advanced-tutorial>`"
msgstr ":ref:`Tutoriel avancé <logging-advanced-tutorial>`"

#: library/logging.config.rst:19
msgid ":ref:`Logging Cookbook <logging-cookbook>`"
msgstr ":ref:`Recettes pour la journalisation <logging-cookbook>`"

#: library/logging.config.rst:23
msgid "This section describes the API for configuring the logging module."
msgstr ""

#: library/logging.config.rst:28
msgid "Configuration functions"
msgstr ""

#: library/logging.config.rst:30
msgid ""
"The following functions configure the logging module. They are located in "
"the :mod:`logging.config` module.  Their use is optional --- you can "
"configure the logging module using these functions or by making calls to the "
"main API (defined in :mod:`logging` itself) and defining handlers which are "
"declared either in :mod:`logging` or :mod:`logging.handlers`."
msgstr ""

#: library/logging.config.rst:38
msgid ""
"Takes the logging configuration from a dictionary.  The contents of this "
"dictionary are described in :ref:`logging-config-dictschema` below."
msgstr ""

#: library/logging.config.rst:42
msgid ""
"If an error is encountered during configuration, this function will raise a :"
"exc:`ValueError`, :exc:`TypeError`, :exc:`AttributeError` or :exc:"
"`ImportError` with a suitably descriptive message.  The following is a "
"(possibly incomplete) list of conditions which will raise an error:"
msgstr ""

#: library/logging.config.rst:48
msgid ""
"A ``level`` which is not a string or which is a string not corresponding to "
"an actual logging level."
msgstr ""

#: library/logging.config.rst:50
msgid "A ``propagate`` value which is not a boolean."
msgstr ""

#: library/logging.config.rst:51
msgid "An id which does not have a corresponding destination."
msgstr ""

#: library/logging.config.rst:52
msgid "A non-existent handler id found during an incremental call."
msgstr ""

#: library/logging.config.rst:53
msgid "An invalid logger name."
msgstr ""

#: library/logging.config.rst:54
msgid "Inability to resolve to an internal or external object."
msgstr ""

#: library/logging.config.rst:56
msgid ""
"Parsing is performed by the :class:`DictConfigurator` class, whose "
"constructor is passed the dictionary used for configuration, and has a :meth:"
"`configure` method.  The :mod:`logging.config` module has a callable "
"attribute :attr:`dictConfigClass` which is initially set to :class:"
"`DictConfigurator`. You can replace the value of :attr:`dictConfigClass` "
"with a suitable implementation of your own."
msgstr ""

#: library/logging.config.rst:64
msgid ""
":func:`dictConfig` calls :attr:`dictConfigClass` passing the specified "
"dictionary, and then calls the :meth:`configure` method on the returned "
"object to put the configuration into effect::"
msgstr ""

#: library/logging.config.rst:71
msgid ""
"For example, a subclass of :class:`DictConfigurator` could call "
"``DictConfigurator.__init__()`` in its own :meth:`__init__()`, then set up "
"custom prefixes which would be usable in the subsequent :meth:`configure` "
"call. :attr:`dictConfigClass` would be bound to this new subclass, and then :"
"func:`dictConfig` could be called exactly as in the default, uncustomized "
"state."
msgstr ""

#: library/logging.config.rst:82
msgid ""
"Reads the logging configuration from a :mod:`configparser`\\-format file. "
"The format of the file should be as described in :ref:`logging-config-"
"fileformat`. This function can be called several times from an application, "
"allowing an end user to select from various pre-canned configurations (if "
"the developer provides a mechanism to present the choices and load the "
"chosen configuration)."
msgstr ""

#: library/logging.config.rst:0
msgid "Parameters"
msgstr "Paramètres"

#: library/logging.config.rst:90
msgid ""
"A filename, or a file-like object, or an instance derived from :class:"
"`~configparser.RawConfigParser`. If a ``RawConfigParser``-derived instance "
"is passed, it is used as is. Otherwise, a :class:`~configparser."
"Configparser` is instantiated, and the configuration read by it from the "
"object passed in ``fname``. If that has a :meth:`readline` method, it is "
"assumed to be a file-like object and read using :meth:`~configparser."
"ConfigParser.read_file`; otherwise, it is assumed to be a filename and "
"passed to :meth:`~configparser.ConfigParser.read`."
msgstr ""

#: library/logging.config.rst:102
msgid ""
"Defaults to be passed to the ConfigParser can be specified in this argument."
msgstr ""

#: library/logging.config.rst:105
msgid ""
"If specified as ``False``, loggers which                                 "
"exist when this call is made are left                                 "
"enabled. The default is ``True`` because "
"this                                 enables old behaviour in "
"a                                 backward-compatible way. This behaviour is "
"to                                 disable any existing non-root loggers "
"unless                                 they or their ancestors are "
"explicitly named                                 in the logging "
"configuration.  :param encoding: The encoding used to open file when *fname* "
"is filename."
msgstr ""

#: library/logging.config.rst:112
msgid "If specified as ``False``, loggers which"
msgstr ""

#: library/logging.config.rst:106
msgid ""
"exist when this call is made are left enabled. The default is ``True`` "
"because this enables old behaviour in a backward-compatible way. This "
"behaviour is to disable any existing non-root loggers unless they or their "
"ancestors are explicitly named in the logging configuration."
msgstr ""

#: library/logging.config.rst:0
msgid "param encoding"
msgstr ""

#: library/logging.config.rst:114
msgid "The encoding used to open file when *fname* is filename."
msgstr ""

#: library/logging.config.rst:116
msgid ""
"An instance of a subclass of :class:`~configparser.RawConfigParser` is   now "
"accepted as a value for ``fname``. This facilitates:"
msgstr ""

#: library/logging.config.rst:120
msgid ""
"Use of a configuration file where logging configuration is just part of the "
"overall application configuration."
msgstr ""

#: library/logging.config.rst:122
msgid ""
"Use of a configuration read from a file, and then modified by the using "
"application (e.g. based on command-line parameters or other aspects of the "
"runtime environment) before being passed to ``fileConfig``."
msgstr ""

#: library/logging.config.rst:126
msgid "The *encoding* parameter is added."
msgstr ""

#: library/logging.config.rst:131
msgid ""
"Starts up a socket server on the specified port, and listens for new "
"configurations. If no port is specified, the module's default :const:"
"`DEFAULT_LOGGING_CONFIG_PORT` is used. Logging configurations will be sent "
"as a file suitable for processing by :func:`dictConfig` or :func:"
"`fileConfig`. Returns a :class:`~threading.Thread` instance on which you can "
"call :meth:`~threading.Thread.start` to start the server, and which you can :"
"meth:`~threading.Thread.join` when appropriate. To stop the server, call :"
"func:`stopListening`."
msgstr ""

#: library/logging.config.rst:140
msgid ""
"The ``verify`` argument, if specified, should be a callable which should "
"verify whether bytes received across the socket are valid and should be "
"processed. This could be done by encrypting and/or signing what is sent "
"across the socket, such that the ``verify`` callable can perform signature "
"verification and/or decryption. The ``verify`` callable is called with a "
"single argument - the bytes received across the socket - and should return "
"the bytes to be processed, or ``None`` to indicate that the bytes should be "
"discarded. The returned bytes could be the same as the passed in bytes (e.g. "
"when only verification is done), or they could be completely different "
"(perhaps if decryption were performed)."
msgstr ""

#: library/logging.config.rst:151
msgid ""
"To send a configuration to the socket, read in the configuration file and "
"send it to the socket as a sequence of bytes preceded by a four-byte length "
"string packed in binary using ``struct.pack('>L', n)``."
msgstr ""

#: library/logging.config.rst:159
msgid ""
"Because portions of the configuration are passed through :func:`eval`, use "
"of this function may open its users to a security risk. While the function "
"only binds to a socket on ``localhost``, and so does not accept connections "
"from remote machines, there are scenarios where untrusted code could be run "
"under the account of the process which calls :func:`listen`. Specifically, "
"if the process calling :func:`listen` runs on a multi-user machine where "
"users cannot trust each other, then a malicious user could arrange to run "
"essentially arbitrary code in a victim user's process, simply by connecting "
"to the victim's :func:`listen` socket and sending a configuration which runs "
"whatever code the attacker wants to have executed in the victim's process. "
"This is especially easy to do if the default port is used, but not hard even "
"if a different port is used. To avoid the risk of this happening, use the "
"``verify`` argument to :func:`listen` to prevent unrecognised configurations "
"from being applied."
msgstr ""

#: library/logging.config.rst:175
msgid "The ``verify`` argument was added."
msgstr ""

#: library/logging.config.rst:180
msgid ""
"If you want to send configurations to the listener which don't disable "
"existing loggers, you will need to use a JSON format for the configuration, "
"which will use :func:`dictConfig` for configuration. This method allows you "
"to specify ``disable_existing_loggers`` as ``False`` in the configuration "
"you send."
msgstr ""

#: library/logging.config.rst:189
msgid ""
"Stops the listening server which was created with a call to :func:`listen`. "
"This is typically called before calling :meth:`join` on the return value "
"from :func:`listen`."
msgstr ""

#: library/logging.config.rst:195
msgid "Security considerations"
msgstr ""

#: library/logging.config.rst:197
msgid ""
"The logging configuration functionality tries to offer convenience, and in "
"part this is done by offering the ability to convert text in configuration "
"files into Python objects used in logging configuration - for example, as "
"described in :ref:`logging-config-dict-userdef`. However, these same "
"mechanisms (importing callables from user-defined modules and calling them "
"with parameters from the configuration) could be used to invoke any code you "
"like, and for this reason you should treat configuration files from "
"untrusted sources with *extreme caution* and satisfy yourself that nothing "
"bad can happen if you load them, before actually loading them."
msgstr ""

#: library/logging.config.rst:211
msgid "Configuration dictionary schema"
msgstr ""

#: library/logging.config.rst:213
msgid ""
"Describing a logging configuration requires listing the various objects to "
"create and the connections between them; for example, you may create a "
"handler named 'console' and then say that the logger named 'startup' will "
"send its messages to the 'console' handler. These objects aren't limited to "
"those provided by the :mod:`logging` module because you might write your own "
"formatter or handler class. The parameters to these classes may also need to "
"include external objects such as ``sys.stderr``.  The syntax for describing "
"these objects and connections is defined in :ref:`logging-config-dict-"
"connections` below."
msgstr ""

#: library/logging.config.rst:225
msgid "Dictionary Schema Details"
msgstr ""

#: library/logging.config.rst:227
msgid ""
"The dictionary passed to :func:`dictConfig` must contain the following keys:"
msgstr ""

#: library/logging.config.rst:230
msgid ""
"*version* - to be set to an integer value representing the schema version.  "
"The only valid value at present is 1, but having this key allows the schema "
"to evolve while still preserving backwards compatibility."
msgstr ""

#: library/logging.config.rst:235
msgid ""
"All other keys are optional, but if present they will be interpreted as "
"described below.  In all cases below where a 'configuring dict' is "
"mentioned, it will be checked for the special ``'()'`` key to see if a "
"custom instantiation is required.  If so, the mechanism described in :ref:"
"`logging-config-dict-userdef` below is used to create an instance; "
"otherwise, the context is used to determine what to instantiate."
msgstr ""

#: library/logging.config.rst:244
msgid ""
"*formatters* - the corresponding value will be a dict in which each key is a "
"formatter id and each value is a dict describing how to configure the "
"corresponding :class:`~logging.Formatter` instance."
msgstr ""

#: library/logging.config.rst:248
msgid ""
"The configuring dict is searched for the following optional keys which "
"correspond to the arguments passed to create a :class:`~logging.Formatter` "
"object:"
msgstr ""

#: library/logging.config.rst:252
msgid "``format``"
msgstr ""

#: library/logging.config.rst:253
msgid "``datefmt``"
msgstr ""

#: library/logging.config.rst:254
msgid "``style``"
msgstr ""

#: library/logging.config.rst:255
msgid "``validate`` (since version >=3.8)"
msgstr ""

#: library/logging.config.rst:257
msgid ""
"An optional ``class`` key indicates the name of the formatter's class (as a "
"dotted module and class name).  The instantiation arguments are as for :"
"class:`~logging.Formatter`, thus this key is most useful for instantiating a "
"customised subclass of :class:`~logging.Formatter`.  For example, the "
"alternative class might present exception tracebacks in an expanded or "
"condensed format.  If your formatter requires different or extra "
"configuration keys, you should use :ref:`logging-config-dict-userdef`."
msgstr ""

#: library/logging.config.rst:266
msgid ""
"*filters* - the corresponding value will be a dict in which each key is a "
"filter id and each value is a dict describing how to configure the "
"corresponding Filter instance."
msgstr ""

#: library/logging.config.rst:270
msgid ""
"The configuring dict is searched for the key ``name`` (defaulting to the "
"empty string) and this is used to construct a :class:`logging.Filter` "
"instance."
msgstr ""

#: library/logging.config.rst:274
msgid ""
"*handlers* - the corresponding value will be a dict in which each key is a "
"handler id and each value is a dict describing how to configure the "
"corresponding Handler instance."
msgstr ""

#: library/logging.config.rst:323
msgid "The configuring dict is searched for the following keys:"
msgstr ""

#: library/logging.config.rst:280
msgid ""
"``class`` (mandatory).  This is the fully qualified name of the handler "
"class."
msgstr ""

#: library/logging.config.rst:283
msgid "``level`` (optional).  The level of the handler."
msgstr ""

#: library/logging.config.rst:285
msgid "``formatter`` (optional).  The id of the formatter for this handler."
msgstr ""

#: library/logging.config.rst:288
msgid "``filters`` (optional).  A list of ids of the filters for this handler."
msgstr ""

#: library/logging.config.rst:332
msgid "``filters`` can take filter instances in addition to ids."
msgstr ""

#: library/logging.config.rst:294
msgid ""
"All *other* keys are passed through as keyword arguments to the handler's "
"constructor.  For example, given the snippet:"
msgstr ""

#: library/logging.config.rst:313
msgid ""
"the handler with id ``console`` is instantiated as a :class:`logging."
"StreamHandler`, using ``sys.stdout`` as the underlying stream.  The handler "
"with id ``file`` is instantiated as a :class:`logging.handlers."
"RotatingFileHandler` with the keyword arguments ``filename='logconfig.log', "
"maxBytes=1024, backupCount=3``."
msgstr ""

#: library/logging.config.rst:319
msgid ""
"*loggers* - the corresponding value will be a dict in which each key is a "
"logger name and each value is a dict describing how to configure the "
"corresponding Logger instance."
msgstr ""

#: library/logging.config.rst:325
msgid "``level`` (optional).  The level of the logger."
msgstr ""

#: library/logging.config.rst:327
msgid "``propagate`` (optional).  The propagation setting of the logger."
msgstr ""

#: library/logging.config.rst:329
msgid "``filters`` (optional).  A list of ids of the filters for this logger."
msgstr ""

#: library/logging.config.rst:335
msgid ""
"``handlers`` (optional).  A list of ids of the handlers for this logger."
msgstr ""

#: library/logging.config.rst:338
msgid ""
"The specified loggers will be configured according to the level, "
"propagation, filters and handlers specified."
msgstr ""

#: library/logging.config.rst:341
msgid ""
"*root* - this will be the configuration for the root logger. Processing of "
"the configuration will be as for any logger, except that the ``propagate`` "
"setting will not be applicable."
msgstr ""

#: library/logging.config.rst:345
msgid ""
"*incremental* - whether the configuration is to be interpreted as "
"incremental to the existing configuration.  This value defaults to "
"``False``, which means that the specified configuration replaces the "
"existing configuration with the same semantics as used by the existing :func:"
"`fileConfig` API."
msgstr ""

#: library/logging.config.rst:351
msgid ""
"If the specified value is ``True``, the configuration is processed as "
"described in the section on :ref:`logging-config-dict-incremental`."
msgstr ""

#: library/logging.config.rst:354
msgid ""
"*disable_existing_loggers* - whether any existing non-root loggers are to be "
"disabled. This setting mirrors the parameter of the same name in :func:"
"`fileConfig`. If absent, this parameter defaults to ``True``. This value is "
"ignored if *incremental* is ``True``."
msgstr ""

#: library/logging.config.rst:362
msgid "Incremental Configuration"
msgstr ""

#: library/logging.config.rst:364
msgid ""
"It is difficult to provide complete flexibility for incremental "
"configuration.  For example, because objects such as filters and formatters "
"are anonymous, once a configuration is set up, it is not possible to refer "
"to such anonymous objects when augmenting a configuration."
msgstr ""

#: library/logging.config.rst:370
msgid ""
"Furthermore, there is not a compelling case for arbitrarily altering the "
"object graph of loggers, handlers, filters, formatters at run-time, once a "
"configuration is set up; the verbosity of loggers and handlers can be "
"controlled just by setting levels (and, in the case of loggers, propagation "
"flags).  Changing the object graph arbitrarily in a safe way is problematic "
"in a multi-threaded environment; while not impossible, the benefits are not "
"worth the complexity it adds to the implementation."
msgstr ""

#: library/logging.config.rst:379
msgid ""
"Thus, when the ``incremental`` key of a configuration dict is present and is "
"``True``, the system will completely ignore any ``formatters`` and "
"``filters`` entries, and process only the ``level`` settings in the "
"``handlers`` entries, and the ``level`` and ``propagate`` settings in the "
"``loggers`` and ``root`` entries."
msgstr ""

#: library/logging.config.rst:385
msgid ""
"Using a value in the configuration dict lets configurations to be sent over "
"the wire as pickled dicts to a socket listener. Thus, the logging verbosity "
"of a long-running application can be altered over time with no need to stop "
"and restart the application."
msgstr ""

#: library/logging.config.rst:393
msgid "Object connections"
msgstr ""

#: library/logging.config.rst:395
msgid ""
"The schema describes a set of logging objects - loggers, handlers, "
"formatters, filters - which are connected to each other in an object graph.  "
"Thus, the schema needs to represent connections between the objects.  For "
"example, say that, once configured, a particular logger has attached to it a "
"particular handler.  For the purposes of this discussion, we can say that "
"the logger represents the source, and the handler the destination, of a "
"connection between the two.  Of course in the configured objects this is "
"represented by the logger holding a reference to the handler.  In the "
"configuration dict, this is done by giving each destination object an id "
"which identifies it unambiguously, and then using the id in the source "
"object's configuration to indicate that a connection exists between the "
"source and the destination object with that id."
msgstr ""

#: library/logging.config.rst:409
msgid "So, for example, consider the following YAML snippet:"
msgstr ""

#: library/logging.config.rst:430
msgid ""
"(Note: YAML used here because it's a little more readable than the "
"equivalent Python source form for the dictionary.)"
msgstr ""

#: library/logging.config.rst:433
msgid ""
"The ids for loggers are the logger names which would be used "
"programmatically to obtain a reference to those loggers, e.g. ``foo.bar."
"baz``.  The ids for Formatters and Filters can be any string value (such as "
"``brief``, ``precise`` above) and they are transient, in that they are only "
"meaningful for processing the configuration dictionary and used to determine "
"connections between objects, and are not persisted anywhere when the "
"configuration call is complete."
msgstr ""

#: library/logging.config.rst:441
msgid ""
"The above snippet indicates that logger named ``foo.bar.baz`` should have "
"two handlers attached to it, which are described by the handler ids ``h1`` "
"and ``h2``. The formatter for ``h1`` is that described by id ``brief``, and "
"the formatter for ``h2`` is that described by id ``precise``."
msgstr ""

#: library/logging.config.rst:451
msgid "User-defined objects"
msgstr ""

#: library/logging.config.rst:453
msgid ""
"The schema supports user-defined objects for handlers, filters and "
"formatters.  (Loggers do not need to have different types for different "
"instances, so there is no support in this configuration schema for user-"
"defined logger classes.)"
msgstr ""

#: library/logging.config.rst:458
msgid ""
"Objects to be configured are described by dictionaries which detail their "
"configuration.  In some places, the logging system will be able to infer "
"from the context how an object is to be instantiated, but when a user-"
"defined object is to be instantiated, the system will not know how to do "
"this.  In order to provide complete flexibility for user-defined object "
"instantiation, the user needs to provide a 'factory' - a callable which is "
"called with a configuration dictionary and which returns the instantiated "
"object. This is signalled by an absolute import path to the factory being "
"made available under the special key ``'()'``.  Here's a concrete example:"
msgstr ""

#: library/logging.config.rst:484
msgid ""
"The above YAML snippet defines three formatters.  The first, with id "
"``brief``, is a standard :class:`logging.Formatter` instance with the "
"specified format string.  The second, with id ``default``, has a longer "
"format and also defines the time format explicitly, and will result in a :"
"class:`logging.Formatter` initialized with those two format strings.  Shown "
"in Python source form, the ``brief`` and ``default`` formatters have "
"configuration sub-dictionaries::"
msgstr ""

#: library/logging.config.rst:496
msgid "and::"
msgstr "et ::"

#: library/logging.config.rst:503
msgid ""
"respectively, and as these dictionaries do not contain the special key "
"``'()'``, the instantiation is inferred from the context: as a result, "
"standard :class:`logging.Formatter` instances are created.  The "
"configuration sub-dictionary for the third formatter, with id ``custom``, "
"is::"
msgstr ""

#: library/logging.config.rst:516
msgid ""
"and this contains the special key ``'()'``, which means that user-defined "
"instantiation is wanted.  In this case, the specified factory callable will "
"be used. If it is an actual callable it will be used directly - otherwise, "
"if you specify a string (as in the example) the actual callable will be "
"located using normal import mechanisms. The callable will be called with the "
"**remaining** items in the configuration sub-dictionary as keyword "
"arguments.  In the above example, the formatter with id ``custom`` will be "
"assumed to be returned by the call::"
msgstr ""

#: library/logging.config.rst:528
msgid ""
"The values for keys such as ``bar``, ``spam`` and ``answer`` in the above "
"example should not be configuration dictionaries or references such as "
"``cfg://foo`` or ``ext://bar``, because they will not be processed by the "
"configuration machinery, but passed to the callable as-is."
msgstr ""

#: library/logging.config.rst:533
msgid ""
"The key ``'()'`` has been used as the special key because it is not a valid "
"keyword parameter name, and so will not clash with the names of the keyword "
"arguments used in the call.  The ``'()'`` also serves as a mnemonic that the "
"corresponding value is a callable."
msgstr ""

#: library/logging.config.rst:538
msgid ""
"The ``filters`` member of ``handlers`` and ``loggers`` can take filter "
"instances in addition to ids."
msgstr ""

#: library/logging.config.rst:542
msgid ""
"You can also specify a special key ``'.'`` whose value is a dictionary is a "
"mapping of attribute names to values. If found, the specified attributes "
"will be set on the user-defined object before it is returned. Thus, with the "
"following configuration::"
msgstr ""

#: library/logging.config.rst:558
msgid ""
"the returned formatter will have attribute ``foo`` set to ``'bar'`` and "
"attribute ``baz`` set to ``'bozz'``."
msgstr ""

#: library/logging.config.rst:561
msgid ""
"The values for attributes such as ``foo`` and ``baz`` in the above example "
"should not be configuration dictionaries or references such as ``cfg://foo`` "
"or ``ext://bar``, because they will not be processed by the configuration "
"machinery, but set as attribute values as-is."
msgstr ""

#: library/logging.config.rst:570
msgid "Handler configuration order"
msgstr ""

#: library/logging.config.rst:572
msgid ""
"Handlers are configured in alphabetical order of their keys, and a "
"configured handler replaces the configuration dictionary in (a working copy "
"of) the ``handlers`` dictionary in the schema. If you use a construct such "
"as ``cfg://handlers.foo``, then initially ``handlers['foo']`` points to the "
"configuration dictionary for the handler named ``foo``, and later (once that "
"handler has been configured) it points to the configured handler instance. "
"Thus, ``cfg://handlers.foo`` could resolve to either a dictionary or a "
"handler instance. In general, it is wise to name handlers in a way such that "
"dependent handlers are configured _after_ any handlers they depend on; that "
"allows something like ``cfg://handlers.foo`` to be used in configuring a "
"handler that depends on handler ``foo``. If that dependent handler were "
"named ``bar``, problems would result, because the configuration of ``bar`` "
"would be attempted before that of ``foo``, and ``foo`` would not yet have "
"been configured. However, if the dependent handler were named ``foobar``, it "
"would be configured after ``foo``, with the result that ``cfg://handlers."
"foo`` would resolve to configured handler ``foo``, and not its configuration "
"dictionary."
msgstr ""

#: library/logging.config.rst:593
msgid "Access to external objects"
msgstr ""

#: library/logging.config.rst:595
msgid ""
"There are times where a configuration needs to refer to objects external to "
"the configuration, for example ``sys.stderr``.  If the configuration dict is "
"constructed using Python code, this is straightforward, but a problem arises "
"when the configuration is provided via a text file (e.g. JSON, YAML).  In a "
"text file, there is no standard way to distinguish ``sys.stderr`` from the "
"literal string ``'sys.stderr'``.  To facilitate this distinction, the "
"configuration system looks for certain special prefixes in string values and "
"treat them specially.  For example, if the literal string ``'ext://sys."
"stderr'`` is provided as a value in the configuration, then the ``ext://`` "
"will be stripped off and the remainder of the value processed using normal "
"import mechanisms."
msgstr ""

#: library/logging.config.rst:608
msgid ""
"The handling of such prefixes is done in a way analogous to protocol "
"handling: there is a generic mechanism to look for prefixes which match the "
"regular expression ``^(?P<prefix>[a-z]+)://(?P<suffix>.*)$`` whereby, if the "
"``prefix`` is recognised, the ``suffix`` is processed in a prefix-dependent "
"manner and the result of the processing replaces the string value.  If the "
"prefix is not recognised, then the string value will be left as-is."
msgstr ""

#: library/logging.config.rst:620
msgid "Access to internal objects"
msgstr ""

#: library/logging.config.rst:622
msgid ""
"As well as external objects, there is sometimes also a need to refer to "
"objects in the configuration.  This will be done implicitly by the "
"configuration system for things that it knows about.  For example, the "
"string value ``'DEBUG'`` for a ``level`` in a logger or handler will "
"automatically be converted to the value ``logging.DEBUG``, and the "
"``handlers``, ``filters`` and ``formatter`` entries will take an object id "
"and resolve to the appropriate destination object."
msgstr ""

#: library/logging.config.rst:630
msgid ""
"However, a more generic mechanism is needed for user-defined objects which "
"are not known to the :mod:`logging` module.  For example, consider :class:"
"`logging.handlers.MemoryHandler`, which takes a ``target`` argument which is "
"another handler to delegate to. Since the system already knows about this "
"class, then in the configuration, the given ``target`` just needs to be the "
"object id of the relevant target handler, and the system will resolve to the "
"handler from the id.  If, however, a user defines a ``my.package.MyHandler`` "
"which has an ``alternate`` handler, the configuration system would not know "
"that the ``alternate`` referred to a handler.  To cater for this, a generic "
"resolution system allows the user to specify:"
msgstr ""

#: library/logging.config.rst:652
msgid ""
"The literal string ``'cfg://handlers.file'`` will be resolved in an "
"analogous way to strings with the ``ext://`` prefix, but looking in the "
"configuration itself rather than the import namespace.  The mechanism allows "
"access by dot or by index, in a similar way to that provided by ``str."
"format``.  Thus, given the following snippet:"
msgstr ""

#: library/logging.config.rst:670
msgid ""
"in the configuration, the string ``'cfg://handlers'`` would resolve to the "
"dict with key ``handlers``, the string ``'cfg://handlers.email`` would "
"resolve to the dict with key ``email`` in the ``handlers`` dict, and so on.  "
"The string ``'cfg://handlers.email.toaddrs[1]`` would resolve to "
"``'dev_team@domain.tld'`` and the string ``'cfg://handlers.email."
"toaddrs[0]'`` would resolve to the value ``'support_team@domain.tld'``. The "
"``subject`` value could be accessed using either ``'cfg://handlers.email."
"subject'`` or, equivalently, ``'cfg://handlers.email[subject]'``.  The "
"latter form only needs to be used if the key contains spaces or non-"
"alphanumeric characters.  If an index value consists only of decimal digits, "
"access will be attempted using the corresponding integer value, falling back "
"to the string value if needed."
msgstr ""

#: library/logging.config.rst:684
msgid ""
"Given a string ``cfg://handlers.myhandler.mykey.123``, this will resolve to "
"``config_dict['handlers']['myhandler']['mykey']['123']``. If the string is "
"specified as ``cfg://handlers.myhandler.mykey[123]``, the system will "
"attempt to retrieve the value from ``config_dict['handlers']['myhandler']"
"['mykey'][123]``, and fall back to ``config_dict['handlers']['myhandler']"
"['mykey']['123']`` if that fails."
msgstr ""

#: library/logging.config.rst:696
msgid "Import resolution and custom importers"
msgstr ""

#: library/logging.config.rst:698
msgid ""
"Import resolution, by default, uses the builtin :func:`__import__` function "
"to do its importing. You may want to replace this with your own importing "
"mechanism: if so, you can replace the :attr:`importer` attribute of the :"
"class:`DictConfigurator` or its superclass, the :class:`BaseConfigurator` "
"class. However, you need to be careful because of the way functions are "
"accessed from classes via descriptors. If you are using a Python callable to "
"do your imports, and you want to define it at class level rather than "
"instance level, you need to wrap it with :func:`staticmethod`. For example::"
msgstr ""

#: library/logging.config.rst:713
msgid ""
"You don't need to wrap with :func:`staticmethod` if you're setting the "
"import callable on a configurator *instance*."
msgstr ""

#: library/logging.config.rst:720
msgid "Configuration file format"
msgstr ""

#: library/logging.config.rst:722
msgid ""
"The configuration file format understood by :func:`fileConfig` is based on :"
"mod:`configparser` functionality. The file must contain sections called "
"``[loggers]``, ``[handlers]`` and ``[formatters]`` which identify by name "
"the entities of each type which are defined in the file. For each such "
"entity, there is a separate section which identifies how that entity is "
"configured.  Thus, for a logger named ``log01`` in the ``[loggers]`` "
"section, the relevant configuration details are held in a section "
"``[logger_log01]``. Similarly, a handler called ``hand01`` in the "
"``[handlers]`` section will have its configuration held in a section called "
"``[handler_hand01]``, while a formatter called ``form01`` in the "
"``[formatters]`` section will have its configuration specified in a section "
"called ``[formatter_form01]``. The root logger configuration must be "
"specified in a section called ``[logger_root]``."
msgstr ""

#: library/logging.config.rst:737
msgid ""
"The :func:`fileConfig` API is older than the :func:`dictConfig` API and does "
"not provide functionality to cover certain aspects of logging. For example, "
"you cannot configure :class:`~logging.Filter` objects, which provide for "
"filtering of messages beyond simple integer levels, using :func:"
"`fileConfig`. If you need to have instances of :class:`~logging.Filter` in "
"your logging configuration, you will need to use :func:`dictConfig`. Note "
"that future enhancements to configuration functionality will be added to :"
"func:`dictConfig`, so it's worth considering transitioning to this newer API "
"when it's convenient to do so."
msgstr ""

#: library/logging.config.rst:747
msgid "Examples of these sections in the file are given below."
msgstr ""

#: library/logging.config.rst:760
msgid ""
"The root logger must specify a level and a list of handlers. An example of a "
"root logger section is given below."
msgstr ""

#: library/logging.config.rst:769
msgid ""
"The ``level`` entry can be one of ``DEBUG, INFO, WARNING, ERROR, CRITICAL`` "
"or ``NOTSET``. For the root logger only, ``NOTSET`` means that all messages "
"will be logged. Level values are :ref:`evaluated <func-eval>` in the context "
"of the ``logging`` package's namespace."
msgstr ""

#: library/logging.config.rst:774
msgid ""
"The ``handlers`` entry is a comma-separated list of handler names, which "
"must appear in the ``[handlers]`` section. These names must appear in the "
"``[handlers]`` section and have corresponding sections in the configuration "
"file."
msgstr ""

#: library/logging.config.rst:779
msgid ""
"For loggers other than the root logger, some additional information is "
"required. This is illustrated by the following example."
msgstr ""

#: library/logging.config.rst:790
msgid ""
"The ``level`` and ``handlers`` entries are interpreted as for the root "
"logger, except that if a non-root logger's level is specified as ``NOTSET``, "
"the system consults loggers higher up the hierarchy to determine the "
"effective level of the logger. The ``propagate`` entry is set to 1 to "
"indicate that messages must propagate to handlers higher up the logger "
"hierarchy from this logger, or 0 to indicate that messages are **not** "
"propagated to handlers up the hierarchy. The ``qualname`` entry is the "
"hierarchical channel name of the logger, that is to say the name used by the "
"application to get the logger."
msgstr ""

#: library/logging.config.rst:799
msgid ""
"Sections which specify handler configuration are exemplified by the "
"following."
msgstr ""

#: library/logging.config.rst:809
msgid ""
"The ``class`` entry indicates the handler's class (as determined by :func:"
"`eval` in the ``logging`` package's namespace). The ``level`` is interpreted "
"as for loggers, and ``NOTSET`` is taken to mean 'log everything'."
msgstr ""

#: library/logging.config.rst:813
msgid ""
"The ``formatter`` entry indicates the key name of the formatter for this "
"handler. If blank, a default formatter (``logging._defaultFormatter``) is "
"used. If a name is specified, it must appear in the ``[formatters]`` section "
"and have a corresponding section in the configuration file."
msgstr ""

#: library/logging.config.rst:818
msgid ""
"The ``args`` entry, when :ref:`evaluated <func-eval>` in the context of the "
"``logging`` package's namespace, is the list of arguments to the constructor "
"for the handler class. Refer to the constructors for the relevant handlers, "
"or to the examples below, to see how typical entries are constructed. If not "
"provided, it defaults to ``()``."
msgstr ""

#: library/logging.config.rst:824
msgid ""
"The optional ``kwargs`` entry, when :ref:`evaluated <func-eval>` in the "
"context of the ``logging`` package's namespace, is the keyword argument dict "
"to the constructor for the handler class. If not provided, it defaults to "
"``{}``."
msgstr ""

#: library/logging.config.rst:881
msgid ""
"Sections which specify formatter configuration are typified by the following."
msgstr ""

#: library/logging.config.rst:892
msgid ""
"The arguments for the formatter configuration are the same as the keys in "
"the dictionary schema :ref:`formatters section <logging-config-dictschema-"
"formatters>`."
msgstr ""

#: library/logging.config.rst:898
msgid ""
"Due to the use of :func:`eval` as described above, there are potential "
"security risks which result from using the :func:`listen` to send and "
"receive configurations via sockets. The risks are limited to where multiple "
"users with no mutual trust run code on the same machine; see the :func:"
"`listen` documentation for more information."
msgstr ""

#: library/logging.config.rst:907
msgid "Module :mod:`logging`"
msgstr "Module :mod:`logging`"

#: library/logging.config.rst:907
msgid "API reference for the logging module."
msgstr "Référence d'API pour le module de journalisation."

#: library/logging.config.rst:909
msgid "Module :mod:`logging.handlers`"
msgstr "Module :mod:`logging.handlers`"

#: library/logging.config.rst:910
msgid "Useful handlers included with the logging module."
msgstr "Gestionnaires utiles inclus avec le module de journalisation."