Vinay Sajip wrote: > A little while ago, I posted here a suggestion about a new way to configure > logging, using dictionaries. This received some positive and no negative > feedback, so I have thought some more about the details of how it might work. > I > present below the results of that thinking, in a PEP-style format. I don't > know > if an actual PEP is required for a change of this type, but I felt that it's > still worth going through the exercise to try and achieve a reasonable level > of > rigour. (I hope I've succeeded.)
Since part of the purpose of this new configuration option is to allow other projects to use it as a target for specifying a logging configuration, maintaining it as a formal PEP seems like a good idea to me. This is already done for a few other standard-ish interfaces (distutils metadata, DB-API, WSGI). > I would welcome all your feedback on this proposal. If I hear no negative > feedback, I propose to implement this feature as suggested. My only real objection is to the "incremental" flag in the dictionary. I would suggest having two different API methods instead - initDictConfig and updateDictConfig. Or is there some specific reason for having the choice of incremental update vs replacement configuration in the hands of the config author rather than the application developer? My other question is whether or not it would be worth having the logging module able to export it's *current* configuration in dictionary form. I don't have a use case other than that it might be useful for debugging logging configuration errors when attempting to combine multiple sources of logging data, but it's worth considering. > So, for example, consider the following YAML snippet:: > > handers: > h1: #This is an id > # configuration of handler with id h1 goes here > h2: #This is another id > # configuration of handler with id h2 goes here Typo in the header here: s/handers/handlers/ > Configuration Errors > ==================== > > If an error is encountered during configuration, the system will raise a > ``ValueError`` or a ``TypeError`` with a suitably descriptive message. The > following is a (possibly incomplete) list of conditions which will raise an > error: > > * A ``level`` which is not a string or which is a string not corresponding to > an actual logging level > > * A ``propagate`` value which is not a Boolean > > * An id which does not have a corresponding destination > > * An invalid logger name You may want to allow yourself AttributeError and ImportError here. Alternatively, you could commit to converting those to an appropriate ValueError that provides more detail on the config setting that contained the problematic reference. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
