파이썬에서 인쇄 대신 로깅을 사용하는 이유는 무엇입니까?

파이썬에서 인쇄 대신 로깅을 사용하는 이유는 무엇입니까?

복잡한 프로젝트에서 간단한 디버깅을 위해 인쇄 대신 파이썬 로거를 사용해야 하는 이유가 있습니까?다른 사용 사례는 어떻습니까?(특히 stdout만 찾고 있는 경우) 각각에 대해 허용되는 최상의 사용 사례가 있습니까?

저는 항상 이것이 "베스트 프랙티스"라는 말을 들었지만, 그 이유를 알 수 없었습니다.

로깅 패키지에는 다음과 같은 유용한 기능이 많이 있습니다.

• 로깅 통화가 발신되는 위치와 시간(심지어 어떤 회선 번호)을 쉽게 확인할 수 있습니다.
• 파일, 소켓, 거의 모든 것에 동시에 로그인할 수 있습니다.
• 심각도에 따라 로깅을 구분할 수 있습니다.

인쇄물에는 이런 것이 없습니다.

또한 프로젝트가 다른 파이썬 도구에 의해 가져오기 위한 것이라면 사용자가 인쇄 메시지가 어디서 왔는지 모를 수 있기 때문에 패키지가 stdout할 내용을 인쇄하는 것은 좋지 않은 관행입니다.로깅을 사용하면 패키지 사용자가 도구에서 로깅 메시지를 전파할지 여부를 선택할 수 있습니다.

적절한 기록의 가장 큰 장점 중 하나는 메시지를 분류하고 필요한 내용에 따라 메시지를 설정하거나 해제할 수 있다는 것입니다.예를 들어 프로젝트의 특정 부분에 대해 디버깅 수준 메시지를 설정하고 다른 부분에 대해서는 설정을 낮춰 정보 오버로드가 발생하지 않도록 하고 로깅이 필요한 작업에 쉽게 집중할 수 있도록 하는 것이 유용할 수 있습니다.

또한 로그를 구성할 수 있습니다.쉽게 필터링하고, 파일로 보내고, 포맷하고, 타임스탬프를 추가하고, 글로벌하게 필요한 모든 항목을 추가할 수 있습니다.인쇄문은 쉽게 관리되지 않습니다.

인쇄문은 온라인 디버거의 부정적인 측면과 진단 도구를 결합한 두 세계 중 가장 나쁜 것입니다.프로그램을 수정해야 하지만 더 많은 유용한 코드를 얻을 수 없습니다.

온라인 디버거를 사용하면 실행 중인 프로그램의 상태를 검사할 수 있습니다. 하지만 실제 디버거의 좋은 점은 디버거 세션 전이나 후에 소스를 수정할 필요가 없다는 것입니다. 프로그램을 디버거에 로드하고 원하는 위치를 디버거에 말하면 모든 준비가 완료됩니다.

응용 프로그램을 설치하려면 사전에 소스 코드를 수정하는 데 약간의 작업이 필요할 수 있지만, 결과적인 진단 출력은 엄청난 양의 세부 정보를 가질 수 있으며 매우 특정한 수준까지 설정하거나 해제할 수 있습니다.파이썬 로깅 모듈은 기록된 메시지뿐만 아니라 이를 호출한 파일과 함수, 트레이스백(Traceback), 메시지가 전송된 실제 시간 등을 표시할 수 있습니다.그 이상; 진단 장비는 절대 제거할 필요가 없습니다.이 기능은 프로그램이 완료되고 운영 중인 경우 추가된 날짜와 마찬가지로 유효하고 유용합니다. 그러나 로그 파일에 출력이 남아 있어 누구에게도 방해가 되지 않거나 로그 수준을 낮춰 가장 긴급한 메시지를 제외한 모든 메시지를 차단할 수 있습니다.

디버거의 필요성이나 사용을 예측하는 것은 테스트하는 동안 ipython을 사용하고 내장된 pdb 디버거를 제어하는 데 사용하는 명령에 익숙해지는 것보다 어렵지 않습니다.

pdb를 사용하는 것보다 인쇄 명령문을 사용하는 것이 더 쉬울 수 있다고 생각하면 로거를 사용하는 것이 인쇄 명령문을 사용하고 나중에 제거하는 것보다 프로그램을 작업하기 훨씬 쉬운 상태로 전환합니다.

편집자는 구문 오류로 인쇄 문을 강조 표시하고 주석으로 기록 문을 강조 표시하도록 구성했습니다. 제가 보기에 그렇게 생각하기 때문입니다.

간단히 말해서, 로깅 라이브러리를 사용하는 것의 이점이 더 큽니다.print다음과 같은 이유로:

• 방출되는 것을 제어
• 로그에 포함할 정보 유형 정의
• 배출 시 표시 방식 구성
• 가장 중요한 것은 로그의 대상을 설정하는 것입니다.

---

세부적으로 로그 이벤트를 심각도 수준별로 분할하는 것은 특정 시간에 로그 메시지가 가장 관련성이 높은 항목을 선별하는 데 좋은 방법입니다.또한 로그 이벤트의 심각도 수준은 특정 메시지를 볼 때 얼마나 걱정해야 하는지 알려줍니다.예를 들어 로깅 유형을 디버그, 정보, 경고, 심각 및 오류로 분할합니다.애플리케이션에서 무엇이 잘못되었는지 이해하려고 할 때는 타이밍이 모든 것이 될 수 있습니다.다음과 같은 질문에 대한 답을 알고자 합니다.

• "데이터베이스 연결이 끊어지기 전이나 후에 발생했습니까?"
• "정확히 언제 그 요청이 들어왔습니까?"

또한 어떤 스레드에서도 행 번호와 파일 이름 또는 메서드 이름을 통해 로그가 발생한 위치를 쉽게 확인할 수 있습니다.

---

여기 loguru라는 이름의 Python용 기능성 로깅 라이브러리가 있습니다.

로그를 사용하는 경우 배포 담당자가 로그를 사용자 지정 정보와 함께 사용자 지정 위치로 보내도록 로거를 구성할 수 있습니다.인쇄만 하면 됩니다.

로깅은 기본적으로 다른 메타데이터(타임 스탬프, 로그 수준, 라인 번호, 프로세스 등)와 함께 인쇄 출력의 검색 가능한 일반 텍스트 데이터베이스를 만듭니다.

이것은 순금입니다. 파이썬 스크립트가 실행된 후 로그 파일에 대한 egrep를 실행할 수 있습니다.나는 내가 관심 있는 것을 정확히 선택하고 나머지는 무시하도록 나의 egrep 패턴 검색을 조정할 수 있습니다.이러한 인지 부하의 감소와 나중에 시행착오를 통해 나의 egrep 패턴을 선택할 수 있는 자유가 저에게 중요한 이점입니다.

tail -f mylogfile.log | egrep "key_word1|key_word2"

이제 인쇄가 수행할 수 없는 다른 멋진 작업(소켓으로 보내기, 디버그 수준 설정, 로그 회전, 메타데이터 추가 등)을 입력하면 일반 인쇄문보다 로깅을 선호할 이유가 충분합니다.

저는 게으르고 쉽기 때문에 인쇄문을 사용하는 경향이 있습니다. 로깅을 추가하려면 보일러 플레이트 코드가 필요합니다. 야스니펫(이맥)과 울트라닙(빔) 및 기타 템플릿 도구가 있는데, 일반 인쇄문에 대한 로깅을 포기하는 이유는 무엇입니까?

언급된 다른 모든 장점에 표준 구성의 인쇄 기능이 버퍼링된다는 점을 추가하겠습니다.플러시는 현재 블록(인쇄가 있는 블록)의 끝에서만 발생할 수 있습니다.이는 비인터랙티브 셸(예: 코드 빌드, gitlab-ci)에서 시작되거나 출력이 리디렉션되는 모든 프로그램에 해당됩니다.

어떤 이유로든 프로그램이 중지된 경우(킬 -9, 컴퓨터 하드 재설정 등) 동일하게 인쇄를 사용한 경우 로그 줄이 누락될 수 있습니다.

그러나 로깅 라이브러리는 호출할 때마다 stderr 및 stdout에 인쇄된 로그를 즉시 플러시합니다.

언급URL : https://stackoverflow.com/questions/6918493/in-python-why-use-logging-instead-of-print