Jim Jewett gmail.com> writes:
>
> > I couldn't think of a good reason why it should be possible to overwrite
these
> > values with values from a user-supplied dictionary, other than to spoof log
> > entries in some way. The intention is to stop a user accidentally
overwriting
> > one of the ab
> I couldn't think of a good reason why it should be possible to overwrite these
> values with values from a user-supplied dictionary, other than to spoof log
> entries in some way. The intention is to stop a user accidentally overwriting
> one of the above attributes.
This makes sense, but is it
On 11/29/05, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> But thinking about "Errors should never pass silently", I propose that an
> exception (KeyError seems most appropriate, though here it would be because a
> key was present rather than absent) be thrown if one of the above attribute
> names is su
On 11/22/05, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> On numerous occasions, requests have been made for the ability to easily add
> user-defined data to logging events. For example, a multi-threaded server
> application may want to output specific information to a particular server
> thread (e.g.
On 11/22/05, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> makeRecord will, after doing what it does now, use the extra_info argument
> as follows:
>
> If type(extra_info) != types.DictType, it will be ignored.
>
> Otherwise, any entries in extra_info whose keys are not already in the
> LogRecord's __di
On numerous occasions, requests have been made for the ability to easily add
user-defined data to logging events. For example, a multi-threaded server
application may want to output specific information to a particular server
thread (e.g. the identity of the client, specific protocol options for th
