[issue21912] Deferred logging may use outdated references

Vinay Sajip added the comment: > Still, I suggest adding this behavior to the documentation. It is already in the documentation. For example, https://docs.python.org/2/library/logging.html#logging.Formatter.format https://docs.python.org/2/howto/logging.html#optimization This behaviour has bee

[issue21912] Deferred logging may use outdated references

Jonas Diemer added the comment: 2014-07-03 16:42 GMT+02:00 Vinay Sajip : > > I "forked" logging and am catching exceptions during the string > formatting > > That might work with Jython and invalidated objects, but in the case of > e.g. CPython (where the objects can't be invalidated/garbage col

[issue21912] Deferred logging may use outdated references

Vinay Sajip added the comment: > but it means that the string formatting is always done Not if you use logger.isEnabledFor(level) as a guard to avoid unnecessary work :-) > I "forked" logging and am catching exceptions during the string formatting That might work with Jython and invalidated o

[issue21912] Deferred logging may use outdated references

Jonas Diemer added the comment: Thanks for the explanation. Throughput is a valid reason. Your workaround does of course work, but it means that the string formatting is always done, even if the message is filtered out. Is this delayed logging behavior documented in any way (maybe I have overr

[issue21912] Deferred logging may use outdated references

Vinay Sajip added the comment: > I don't see a reason to defer the formatting to the actual output of the > messages (other than the current implementation of logging). The current implementation of logging is like that for a reason, even though you may not see it - it defers doing work until

[issue21912] Deferred logging may use outdated references

R. David Murray added the comment: The decision as to whether or not to pass the message along to the next stage is made at numerous points in the pipeline. -- ___ Python tracker __

[issue21912] Deferred logging may use outdated references

Jonas Diemer added the comment: I see your point. The decision whether to log or not is actually made synchronously to the actual logging call, as far as I can tell (i.e. "if self.isEnabledFor..." is checked directly in debug()). So at this place, the formatting could already happen. I don't

[issue21912] Deferred logging may use outdated references

R. David Murray added the comment: The whole point of the logging API is that the message is *not* formatted unless the message is actually emitted. So this is just how logging works, not something that can be fixed, as far as I can see. -- nosy: +r.david.murray _

[issue21912] Deferred logging may use outdated references

Changes by Zachary Ware : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue21912] Deferred logging may use outdated references

Jonas Diemer added the comment: Find attached a demo script that causes the erratic behavior in regular Python (2.7.5 on Windows). The log file contains two lines, both show the new name of the object, although the first debug() was called befor the name change. I think this problem could be

[issue21912] Deferred logging may use outdated references

New submission from Jonas Diemer: I was having trouble with the logging module under Jython: I was getting seemingly sporadic wierd null pointer exceptions in the logging code. The problem seemed to be related to references that were passed to the logger, e.g. logger.debug("My object: %s", m