Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 337 – 표준 라이브러리에서의 로깅 사용

Author:
Michael P. Dubner <dubnerm at mindless.com>
Status:
Deferred
Type:
Standards Track
Created:
02-Oct-2004
Python-Version:
2.5
Post-History:
10-Nov-2004

Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 표준 라이브러리에서 로깅 시스템(PEP 282)을 사용하기 위한 표준을 정의합니다.

이 PEP를 구현하면 데몬 애플리케이션 개발이 간소화됩니다. 단점으로, 이 PEP는 많은 표준 모듈에 약간의 수정(다만 백포트 가능한 방식)을 요구합니다.

이 PEP를 구현하고 나면 다음과 같은 필터링 방식을 사용할 수 있습니다:

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

PEP 보류

이 PEP에서 다루는 개념에 대한 추가 탐구는 연기되었습니다. PEP의 목표를 추진하고 피드백을 수집하여 반영하는 데 관심이 있으면서 이를 효과적으로 수행할 충분한 시간을 가진 담당자가 현재 없기 때문입니다.

근거

stdout이나 stderr로 출력하는 것이 실용적이지 않은 상황이 몇 가지 있습니다:

  • 프레임워크가 표준 출력을 파일로 리디렉션하는 것을 허용하지 않고, 대신 다른 형태의 로깅을 사용한다고 가정하는 데몬 애플리케이션. 예로는 *nix 계열의 syslog와 WinNT+의 EventLog가 있습니다.
  • 새 로그 항목마다 별도의 팝업 창(예: 서서히 사라지는 OSD)에 출력하려는 GUI 애플리케이션.

또한 애플리케이션이 출력 항목을 출처나 심각도에 따라 필터링하려는 경우도 있습니다. 이 요구 사항은 단순한 리디렉션으로는 구현할 수 없습니다.

마지막으로, 출력에 이벤트 타임스탬프를 표시해야 하는 경우도 있는데, 이는 로깅 시스템을 사용하면 쉽게 해결할 수 있습니다.

제안

데몬 및 GUI 애플리케이션에서 사용할 수 있는 모든 모듈은 print나 sys.stdout.write 대신 로깅 시스템을 사용하도록 다시 작성해야 합니다.

수정되는 모든 모듈의 시작 부분에는 다음과 같은 코드가 포함되어야 합니다:

import logging

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

Python과 함께 배포되는 표준 라이브러리에 포함된 모든 모듈은 py. [2] 접두사를 사용해야 하며, 그러한 모듈만 이 접두사를 사용해야 합니다(검증할 수 없음). _log를 사용하는 것은 의도적인 것으로, 이를 자동으로 내보내지 않기 위함입니다. 하나의 클래스에서만 로그를 사용하는 모듈의 경우, 다음과 같이 클래스 정의 내부에서 로거를 생성할 수 있습니다:

class XXX:

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

그런 다음 이 클래스는 이 비공개 로거에 로그를 기록하는 접근 메서드를 만들 수 있습니다.

따라서 print와 sys.std{out|err}.write 문은 _log.{debug|info}로, traceback.print_exception은 _log.exception 또는 경우에 따라 _log.debug('...', exc_info=1)로 대체해야 합니다.

모듈 목록

다음은 재작업해야 할 모듈의 (불완전할 수도 있는) 목록입니다:

  • asyncore (dispatcher.log, dispatcher.log_info)
  • BaseHTTPServer (BaseHTTPRequestHandler.log_request, BaseHTTPRequestHandler.log_error, BaseHTTPRequestHandler.log_message)
  • cgi (어쩌면 - cgi.log를 사용하는 사람이 있습니까?)
  • ftplib (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 (if POP3._debugging)
  • profile (if Profile.verbose)
  • robotparser (_debug)
  • smtplib (if SGMLParser.verbose)
  • shlex (if shlex.debug)
  • smtpd (SMTPChannel/PureProxy where print >> DEBUGSTREAM)
  • smtplib (if SMTP.debuglevel)
  • SocketServer (BaseServer.handle_error)
  • telnetlib (if Telnet.debuglevel)
  • threading? (_Verbose._note, Thread.__bootstrap)
  • timeit (Timer.print_exc)
  • trace
  • uu (decode)

이 밖에도 디버그 출력이 주석 처리된 모듈이나 디버그 출력을 추가해야 하는 모듈이 몇 개 있습니다. 예를 들면 다음과 같습니다:

  • urllib

마지막으로, 일부 모듈은 더 많은 디버그 정보를 제공하도록 확장해야 할 수도 있습니다.

논란이 있는 모듈

여기에는 커뮤니티에서 모듈 목록에 추가하자고 제안할 모듈과 모듈 목록에서 제거해야 한다고 말하는 모듈을 나열합니다.

  • tabnanny (check)

로깅 사용 지침

또한 라이브러리 모듈 작성자들이 모두 같은 형식으로 로거 이름을 짓도록 몇 가지 권장 사항을 제공할 수 있습니다. 비표준 라이브러리 모듈은 전체 이름을 딴 로거를 사용할 것을 제안합니다. 따라서 패키지 “dummy”의 하위 패키지 “junk”에 있는 모듈 “spam”의 로거는 “dummy.junk.spam”이라는 이름을 가지게 되며, 물론 같은 하위 패키지의 __init__ 모듈은 “dummy.junk”라는 로거 이름을 가지게 됩니다.

참고 문헌