[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 tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30767] logging must check exc_info correctly
Change by Matthew Patton : -- pull_requests: +3950 ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31763] Add NOTICE level to the logging module
Matthew Patton added the comment: syslog(3) is cited in the code as inspiration and has been the goto definition for logging levels for 40 years across many, many projects. NOTICE is incredibly useful especially to those of us who are sysadmins. Why would Python not implement the full suite of syslog levels? Admittedly the case for ALERT and EMERGENCY might be a stretch. It at least doesn't hobble those who want to use them. Without proper coverage one has to settle for unnecessary jumbling of Noteworthy items being buried in the torrent of Informational but not really interesting items. eg. INFO for attempting a connection. NOTICE for temporary service unavailability or handshake timeout, WARNING (maybe ERROR) for retry exhausted depending on what the failure means to the app. eg. INFO for login attempts. NOTICE for password expiry date approaching, for failed logins (bad username/passwords, locked/expired account), for password change attempts, for temporary Federated Auth connect failure. None of which rise to the level of WARNING. -- ___ Python tracker <https://bugs.python.org/issue31763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 focused PR. diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py index 00a022039d..5c61cd56a1 100644 --- a/Lib/logging/__init__.py +++ b/Lib/logging/__init__.py @@ -533,6 +533,8 @@ class Formatter(object): This default implementation just uses traceback.print_exception() """ +if not isinstance(ei, tuple) or ei[0] is None: +return "" sio = io.StringIO() tb = ei[2] # See issues #9427, #1553375. Commented out for now. @@ -584,9 +586,7 @@ class Formatter(object): if self.usesTime(): record.asctime = self.formatTime(record, self.datefmt) s = self.formatMessage(record) -if (isinstance(record.exc_info, tuple) and record.exc_info[0]): -# Intercept 'Boolean' - causes subscript error if passed to formatException, -# and empty Tuples which emit 'NoneType None' into message. +if record.exc_info: # Cache the traceback text to avoid converting it multiple times # (it's constant anyway) if not record.exc_text: -- ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 some other notation that keeps it a single field is how it should print. -- ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 handy in that regard). Second, why is a string representation of an Integer a problem that needs to force the caller to fix his code? Same with lowercase of a recognized value. "Be liberal in what you accept" would seem to apply here. If it can be trivially reduced to an integer or upcased() to get a match then just do it, and send the corrected value back to the caller. -- ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 caller needs to check the Type before allowing a call to the Formatter to go thru. Should sys.exc_info() have already been called then the Tuple can have a valid frame reference or it's 3 None's. In this last case the Formatter is emitting a naked, zero context "NoneType None" line into the middle of the stack trace which is just annoying and pointless. Again, I probably should have written the guard at the formatter to emit nothing when the field is None. It actually checks for the 2nd and 3rd fields, not the first. -- ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30767] logging must check exc_info correctly
Change by Matthew Patton : -- nosy: +mp5023 ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30767] logging must check exc_info correctly
Change by Matthew Patton : -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31763] Add NOTICE level to the logging module
Change by Matthew Patton : -- keywords: +patch pull_requests: +3932 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31763] Add TRACE level to the logging module
New submission from Matthew Patton : This was inspired by 31732. The logging module has 5 log levels: CRITICAL, ERROR, WARNING, INFO, DEBUG per https://docs.python.org/dev/library/logging.html#logging-levels However syslog(3) has for decades defined NOTICE and I can't think of a good reason why this level was carried through. It serves a very useful distinction from routine and not really attention-worthy messages (INFO) but don't rise to actual WARNINGs. Things like failed authentication attempts are not warnings but also not messages to casually ignore. Hence NOTICE. Individual timed out connection attempts but before all attempts exhausted, and many other examples exist. -- components: Library (Lib) messages: 304168 nosy: mp5023 priority: normal severity: normal status: open title: Add TRACE level to the logging module type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30767] logging must check exc_info correctly
Change by Matthew Patton : -- keywords: +patch pull_requests: +3863 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue30767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
