[issue30767] logging must check exc_info correctly

Vinay Sajip added the comment: > I've triggered it which is why I looked for the problem and offered the > defensive patch. That's why I asked for a small example which used logging as documented and demonstrated a problem. You haven't done that. > As API writers you can NEVER assume your pa

[issue30767] logging must check exc_info correctly

Matthew Patton added the comment: I've triggered it which is why I looked for the problem and offered the defensive patch. As API writers you can NEVER assume your parameters are what you think they should be and just blindly proceed. -- ___ Python

[issue30767] logging must check exc_info correctly

Vinay Sajip added the comment: Matthew Patton: you don't appear to have read the documentation correctly. The formatException() method's exc_info positional parameter is expected to be a normal exception tuple, not just any truthy value. This is clearly stated in the documentation for the met

[issue30767] logging must check exc_info correctly

Change by Matthew Patton : -- pull_requests: +3950 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue30767] logging must check exc_info correctly

Matthew Patton added the comment: I believe this diff addresses the failure of formatException() to check it's parameter's datatype. I still maintain this should be re-opened since it's guaranteed to raise an exception when someone sets 'exc_info=TruthyValue' in kwargs. albeit with a more foc

[issue30767] logging must check exc_info correctly

Matthew Patton added the comment: And the reason to stomp on the "Level " is because by not doing so the message that is a single field (regex/awk) has been converted non-deterministically into two. This is very bad behavior. If emitting the string/int as-is looks wrong then "Level(value)" or

[issue30767] logging must check exc_info correctly

Matthew Patton added the comment: Additionally (probably should have separate PR) the _checkLevel was full of holes. First, it's allowing any Integer which if you're claiming to "check" things is rather silly. At least bounds-check it to GE to NOTSET and LE to CRITICAL (or MAX or something ha

[issue30767] logging must check exc_info correctly

Matthew Patton added the comment: "exc_info which, if it does not evaluate as false", so we provide '1' or 'True'. The IF passes and immediately the formatter tries to dereference it blindly assuming it's Tuple and throws an Exception. Either the Formatter needs to guard itself (best) or the

[issue30767] logging must check exc_info correctly

Raymond Hettinger added the comment: I agree that this should be closed. -- nosy: +rhettinger stage: patch review -> resolved status: pending -> closed ___ Python tracker ___ _

[issue30767] logging must check exc_info correctly

Vinay Sajip added the comment: This is not an issue that needs fixing; the current behaviour is by design. The documentation states about exc_info: "There are two keyword arguments in kwargs which are inspected: exc_info which, if it does not evaluate as false, causes exception information to

[issue30767] logging must check exc_info correctly

Serhiy Storchaka added the comment: PR 3792 breaks existing tests, and it seems to me, that it solves different issue, than reported here. -- nosy: +serhiy.storchaka ___ Python tracker __

[issue30767] logging must check exc_info correctly

Change by Berker Peksag : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue30767] logging must check exc_info correctly

Change by Matthew Patton : -- nosy: +mp5023 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue30767] logging must check exc_info correctly

Change by Matthew Patton : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue30767] logging must check exc_info correctly

Change by Matthew Patton : -- keywords: +patch pull_requests: +3863 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue30767] logging must check exc_info correctly

New submission from Mihail Krivushin: Logging checking `if exc_info:` and this maybe incorrect, due exception instance can have __bool__ method and thus can be false. If this is a case, then error that is return false from __bool__ will cause logging to swallow traceback. We need to check exc_