[Python-Dev] PEP282 and the warnings framework

[Vinay Sajip]

> [trying to strip the discussion down]
> Vinay Sajip wrote:
> > > this is an interesting point. LogRecord is the basic unit of the
current
> > logging.
> > > But you can not pass customized (subclassed) LogRecords without them
> > > beeing wrapped (read: contained) in another LogRecord instance. Thus
> > > you have to e.g. access 'record.msg' in filters.  Why two instances
> > > where one is enough, more flexible and pretty straightforward?
> >
> > There aren't two instances.
>
> and
>
> > ...
> > Next question: how to pass in this information? two choices spring to
mind:
> >
> > 1. Use a keyword argument, extra_info=None. (...) A passed in
> > value would become the extra_info attribute of the LogRecord.
> >
> > 2. Use the "msg" parameter, which all logging calls already have (...)
> >    it can be used by user-derived classes, which will find it in the msg
attribute
> >    of the LogRecord.
>
> are not very consistent statements <wink>.

No, because the first is saying how it *is*, the second is saying how it
*could be*. You see how hard I'm trying to accommodate you? <wink>

> > Slightly OT: There's a lot of people who think that the logging system
> > should be a completely generalized system for event generation and
> > processing. I've shied away from using a word like "Event", preferring
> > "LogRecord" which tries to indicate that this is a focused class for a
> > specific job.
>
> You will find in almost every major software system that events are
> generated, filtered and dispatched. I don't see the a problem if a
> logging module would live to these realities. Just because unix/sysloging

If it's a beneficial side effect you get for free, fine. If it imposes
additional work for the simplest case, not so fine.

> or other software has evolved with string/severity-logging doesn't
> make it todays choice. IMO python's ease of working with classes/types
> *makes* a difference.

Yes, but you are missing the point that you *can* have flexibility of classe
s/types etc., and in my last post I just gave one example of how it could be
done. I'd prefer if you gave a specific critique of the approach I
suggested, indicating why it wouldn't work. For example, a particular
problem you are trying to solve which you just can't, with the existing
functionality or that proposed in my last post.

> In distributed transaction systems logging even provides some
> ACID-guarantees as it is used for driving the 2PC-protocol.
> Think about it a minute.  I don't say that python's logging must
> do this in the standard lib.

Okay, we've got some common ground here. I am not for a minute arguing that
the functionality you want is somehow "wrong". It's all a question of what
goes in the standard lib - at least for now, with the 2.3 release date
approaching. That's my focus, it probably makes me look a bit slow-witted.

> I appreciate your efforts but still disagree with your design decisions.
> This should not prevent us to make a break discussing these issues.

Holger, I'm sorry if you're losing patience with me. As my wife is often
telling me, sometimes I just don't get it ;-(

Thanks for your patience so far,


Vinay


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com