Sorry for joining this discussion a little late... Also, do you have
a URL to the module? Perhaps I missed that post :)
I don't see why we can't support both class-based logging
levels and integer logging levels. The logging module can
simply contain a table that maps classes to levels. Then,
the application can implement filtering in the manner
most convenient for it. For classes, a class set can
be used for filter (with the implication that if a class
is within the set, filter it and its sub classes out).
Or numerically, the app can combine logging levels
like flags.
Sometimes it's nice to structure logging levels as such (I've
used this scheme in my own apps):
level1 = 1 << 0
level2 = 1 << 1
level3 = 1 << 2
debug_level = level1 & level2
logger = Logger ()
# Print everything less than level3
logger.set_debug_level (level3)
... and debug_level can be used as a set.
Classes could work similarly by using a list. Adding a class
could filter out all its subclasses, and the hierarchy can
be structured from more general, harmless errors to more specific
and fatal errors.
... I'm not sure I'm a big fan of having methods describe
severity (as I believe I either saw in a post or read in the PEP).
Some apps might want to bypass the built-in scheme entirely. I
liked the design otherwise though :)
-- Mike
On Thu, May 16 @ 02:54, holger krekel wrote:
> first off, the DebugMessage/InfoMessage/... could
> have a class-level severity property (integer) if one
> really wants to have it for compatibility etc.
>
> this leaves the question how a Message-instance/type is more
> powerful than a tuple(string/integer).
>
> Some thoughts regarding Message-instances/types:
>
> - the convenient logging API and categorization features
> need *not* be changed largely (but the signature of the
> log method should/might be changed)
>
> - beeing forced to totally order all types of messages can
> be difficult. You may want e.g. to log 'TimeoutMessages'
> no matter what the current integer threshold might be.
> why not something like: loginstance.accept(TimeoutMessage)
>
> - Message instances can defer the *construction* of a string
> until it is really needed. (see my other posting for a code
> example). This is more effective if you choose to ignore
> certain messages. This has *nothing* to do with formatting.
>
> - customized messages are powerful and allow more advanced
> filtering than with strings, especially for large apps.
> a connection-logger could choose to ignore a
> TimeoutMessage(socket) based on the target address of the
> socket. doing this with strings is hard (and perlish:-)
>
> - a SocketMessage-class may hold a weakref-list of sockets allowing
> to log 'sock<1>', 'sock<2>' instead of addresses which are
> hard to read. stuff like this is *very* convenient. Again
> there is hardly any performance penalty if SocketMessages
> are ignored.
>
> Maybe the categorization features of the logging
> API make up for some of the (relative) inflexibilities of
> string/integer messages.
>
> But what do you really gain by restricting a message
> to a (string,integer) taking my arguments into account?
>
> regards,
>
> holger
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
`-> (pyth)
--
Michael Gilfix
mgilfix@eecs.tufts.edu
For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4