# 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 \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 `" msgstr ":ref:`Tutoriel basique `" #: library/logging.config.rst:18 msgid ":ref:`Advanced Tutorial `" msgstr ":ref:`Tutoriel avancé `" #: library/logging.config.rst:19 msgid ":ref:`Logging Cookbook `" msgstr ":ref:`Recettes pour la journalisation `" #: 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[a-z]+)://(?P.*)$`` 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 ` 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 ` 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 ` 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 `." 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."