[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: This should be addressed by the fix for bpo-33165 - addition of a stacklevel parameter to the logging APIs. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: > Maybe simply having a class list Thanks, I'm aware of this approach and have considered it. The current patch's skipCallers API seems better than exposing an internal list, but I have held off implementing this in the hope that an approach based on frame annota

[issue16778] Logger.findCaller needs to be smarter

Michael Rohan added the comment: I recently implemented a custom logger derived from Logger and to get the reporting of modules, etc, correct, I implemented the findCaller using the same code as library code with the minor change of if filename == _srcfile: to if filename in [logging._srcfile,

[issue16778] Logger.findCaller needs to be smarter

Nick Coghlan added the comment: My idea is to annotate the frames appropriately so they can be *displayed* differently when showing a traceback (either hiding them entirely or displaying additional information). This would be another use case - annotating the frame to say the logging module shoul

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: > the frame annotations idea discussed in other issues If you mean #19585 and #18861, they seem to be related to exceptions - the logging use case is not exception-related. I couldn't find any other discussions about frame annotations. -- __

[issue16778] Logger.findCaller needs to be smarter

Nick Coghlan added the comment: I think we need to look seriously at the frame annotations idea discussed in other issues. Eliminating noise from tracebacks and correctly reporting user code rather than infrastructure could should be achievable through local state rather than needing global re

[issue16778] Logger.findCaller needs to be smarter

Changes by Antoine Pitrou : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: Too late for 3.4 now, bumping to 3.5. Implementation now uses a set and '__name__' in f.f_globals to match module names passed in - this seems good enough. I plan to commit this as soon as default is updated to 3.5, unless there are alternative suggestions.

[issue16778] Logger.findCaller needs to be smarter

Changes by Vinay Sajip : Added file: http://bugs.python.org/file33283/58f0edef2b19.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue16778] Logger.findCaller needs to be smarter

Changes by Vinay Sajip : Added file: http://bugs.python.org/file28486/aecafebb7880.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: > Passing a globals() instance looks hackish. Agreed it's not ideal, but we're constrained by what's available to compare against via the frame. Apart from globals() there's only really the filename, which isn't ideal either. --

[issue16778] Logger.findCaller needs to be smarter

Antoine Pitrou added the comment: Passing a globals() instance looks hackish. importlib uses another approach: http://hg.python.org/cpython/file/5ef49659935f/Lib/importlib/_bootstrap.py#l303 Note that it is a pity that code objects don't have a __module__ attribute. Perhaps it would be a nice f

[issue16778] Logger.findCaller needs to be smarter

Changes by Vinay Sajip : -- keywords: +patch Added file: http://bugs.python.org/file28472/8756372f0f5f.diff ___ Python tracker ___ ___

[issue16778] Logger.findCaller needs to be smarter

Changes by Vinay Sajip : -- hgrepos: +166 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: I will give this some thought, but it won't be possible to add it to Python 2.x (which is closed for feature additions). Any enhancement in this area would apply to Python 3.4 and later. -- versions: +Python 3.4 -Python 2.7 __

[issue16778] Logger.findCaller needs to be smarter

Glynn Clements added the comment: Subclassing findCaller() is likely to be a bit hairy for the average user, as it deals with some fairly arcane aspects of Python internals. As for mechanism, maybe allow functions/methods to be registered with the logging module, which would store a referencet

[issue16778] Logger.findCaller needs to be smarter

Vinay Sajip added the comment: What about subclassing Logger? Then you could override findCaller() to do whatever you need, as well as adding a notice() method, for example. I agree using the source filename isn't ideal, but it's hard to know how people might arbitrarily wrap logging calls and

[issue16778] Logger.findCaller needs to be smarter

Changes by R. David Murray : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue16778] Logger.findCaller needs to be smarter

New submission from Glynn Clements: The current behaviour of logging.Logger.findCaller() makes it awkward to add custom logging interfaces. E.g. suppose that you define a custom logging level (NOTICE) then add a notice() function (analogous to logging.info() etc), the resulting LogRecord stru