Zusammenfassung

Diese PEP definiert einen Standard für die Nutzung des Logging-Systems (PEP 282) in der Standardbibliothek.

Die Implementierung dieser PEP wird die Entwicklung von Daemon-Anwendungen vereinfachen. Als Nachteil erfordert diese PEP leichte Modifikationen (jedoch rückwärtskompatibel) an einer großen Anzahl von Standardmodulen.

Nach der Implementierung dieser PEP kann das folgende Filterungsschema verwendet werden

logging.getLogger('py.BaseHTTPServer').setLevel(logging.FATAL)

PEP Verschiebung

Die weitere Erforschung der in diesem PEP behandelten Konzepte wurde mangels eines aktuellen Vertreters, der an der Förderung der Ziele des PEP interessiert ist und Feedback sammelt und einarbeitet, sowie über ausreichend verfügbare Zeit zur effektiven Umsetzung, zurückgestellt.

Begründung

Es gibt einige Situationen, in denen die Ausgabe nach stdout oder stderr unpraktisch ist

• Daemon-Anwendungen, bei denen das Framework die Umleitung der Standardausgabe in eine Datei nicht zulässt, sondern eine andere Form des Loggings annimmt. Beispiele sind syslog unter *nix und EventLog unter WinNT+.
• GUI-Anwendungen, die jeden neuen Log-Eintrag in einem separaten Pop-up-Fenster ausgeben möchten (z. B. ein ausblendendes OSD).

Manchmal möchten Anwendungen auch Ausgabe-Einträge basierend auf ihrer Quelle oder Schwere filtern. Diese Anforderung kann nicht mit einfacher Umleitung implementiert werden.

Schließlich muss die Ausgabe manchmal mit Zeitstempeln von Ereignissen markiert werden, was mit dem Logging-System einfach erreicht werden kann.

Vorschlag

Jedes Modul, das für Daemon- und GUI-Anwendungen verwendet werden kann, sollte so umgeschrieben werden, dass es das Logging-System anstelle von print oder sys.stdout.write verwendet.

Am Anfang jedes geänderten Moduls sollte folgender Code stehen

import logging

_log = logging.getLogger('py.<module-name>')

Ein Präfix von py. [2] muss von allen Modulen verwendet werden, die in der Standardbibliothek von Python enthalten sind, und nur von solchen Modulen (nicht überprüfbar). Die Verwendung von _log ist beabsichtigt, da wir es nicht automatisch exportieren wollen. Für Module, die Log nur in einer Klasse verwenden, kann ein Logger innerhalb der Klassendefinition wie folgt erstellt werden

class XXX:

    __log = logging.getLogger('py.<module-name>')

Dann kann diese Klasse Zugriffsmethoden erstellen, um zu diesem privaten Logger zu protokollieren.

Daher sollten print und sys.std{out|err}.write Anweisungen durch _log.{debug|info} ersetzt werden, und traceback.print_exception durch _log.exception oder manchmal _log.debug('...', exc_info=1).

Modulliste

Hier ist eine (möglicherweise unvollständige) Liste von Modulen, die überarbeitet werden müssen

• asyncore (dispatcher.log, dispatcher.log_info)
• BaseHTTPServer (BaseHTTPRequestHandler.log_request, BaseHTTPRequestHandler.log_error, BaseHTTPRequestHandler.log_message)
• cgi (möglicherweise - wird cgi.log von jemandem verwendet?)
• ftplib (falls FTP.debugging)
• gopherlib (get_directory)
• httplib (HTTPResponse, HTTPConnection)
• ihooks (_Verbose)
• imaplib (IMAP4._mesg)
• mhlib (MH.error)
• nntplib (NNTP)
• pipes (Template.makepipeline)
• pkgutil (extend_path)
• platform (_syscmd_ver)
• poplib (falls POP3._debugging)
• profile (falls Profile.verbose)
• robotparser (_debug)
• smtplib (falls SGMLParser.verbose)
• shlex (falls shlex.debug)
• smtpd (SMTPChannel/PureProxy, wo print >> DEBUGSTREAM)
• smtplib (falls SMTP.debuglevel)
• SocketServer (BaseServer.handle_error)
• telnetlib (falls Telnet.debuglevel)
• threading? (_Verbose._note, Thread.__bootstrap)
• timeit (Timer.print_exc)
• trace
• uu (decode)

Zusätzlich gibt es einige Module mit auskommentierter Debug-Ausgabe oder Module, bei denen Debug-Ausgabe hinzugefügt werden sollte. Zum Beispiel

• urllib

Schließlich sollten möglicherweise einige Module erweitert werden, um mehr Debug-Informationen bereitzustellen.

Fragwürdige Module

Hier sind Module aufgeführt, die die Community für die Aufnahme in die Modulliste vorschlagen wird, und Module, die laut Community aus der Modulliste gestrichen werden sollten.

• tabnanny (check)

Richtlinien für die Logging-Nutzung

Außerdem können wir Empfehlungen an Autoren von Bibliotheksmodulen geben, damit diese alle das gleiche Namensformat für Logger verwenden. Ich schlage vor, dass Module außerhalb der Standardbibliothek Logger verwenden sollten, die nach ihren vollständigen Namen benannt sind, so dass ein Modul „spam“ im Unterpaket „junk“ des Pakets „dummy“ als „dummy.junk.spam“ benannt wird und natürlich das __init__ Modul desselben Unterpakets den Loggernamen „dummy.junk“ hat.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.