標題圖片 (C) Tai Kedzierski
轉到片段
這篇文章是有觀點的。
Python 的預設日誌設定沒有幫助；它與我們所期望的「包含電池」的方法背道而馳。
從有用的日誌訊息中，我想知道何時、什麼等級以及什麼資訊。我可能想要它在控制台上，我可能想要它在文件中。
這應該很簡單 - 但在 Python 中，我每次都必須查找如何建立具有自訂檔案處理和字串格式的完整日誌記錄實用程式。
它應該像logger = getLogger()一樣簡單，但是出於某種未知原因的預設行為是提供完全無用的格式，並且沒有明智的預設值的簡寫。
或者我需要下載一些來源不明的 pip 包，相信它沒有被名稱劫持，或者進行一些混淆的洩露。我想到了 2016 年的 leftpad 事件，以及 2024 年的 Revival 劫持攻擊，這在不同的回購系統中本質上是相同的問題。
事實上，任何沒有命名空間的用戶存儲庫都容易受到此攻擊：Node 的npm、Python 的pip、Arch 的AUR、Canonical 的snap ...僅舉幾個允許用戶上傳任何內容的例子。即使命名空間也不能保證信任——我遇到過透過這些管道分發軟體的項目，不是透過項目的名稱，而是透過一些任意的開發人員的綽號，這引起了人們對軟體包真實性的懷疑。我在上一篇關於在工作環境中使用syncthing的文章中給出了關於如何決定是否信任來源的思考過程。
使用者控制的儲存庫中的外部依賴關係是魔鬼，只有當問題的解決方案很複雜時才應該考慮。一般來說，簡單的解決方案應該直接存在於代碼庫中- 最好是自己編寫的，但有時問題只是會進入“足夠麻煩”的空間，使依賴感覺既合理又令人討厭。
答案：寫一次，將其存放在 Github gist 或您自己的「有用片段」儲存庫中。複製並貼上。
複製貼上？呃！
「複製貼上」代碼可能會給任何經驗豐富的編碼人員敲響警鐘。 「不要重複自己」、「使用套件管理器」、「寫一次，隨處更新」。這些都是良好的本能，但根據具體情況，了解何時複製貼上是更好。
在這種情況下，要求是避免不必要的外部依賴以獲得簡單需求的簡單解決方案。在 leftpad 中，與此迷你記錄器一樣，所需的程式碼片段是 short 且 易於理解 ；如果需要的話重新實現也沒有什麼損失。它也獲得了適當的許可（是的，它可能只是一個片段；但是仍然值得推薦，以確保您複製的內容確實是允許的。小心複製隨機的程式碼區塊。）
我在下麵包含了一個迷你記錄器實用程式的程式碼片段，它允許以最少的配置進行一次呼叫：
哪個印到控制台：
將其複製到專案中的 minilogger.py 檔案中。 Tada - 不需要外部依賴。如果不受影響，它將永遠保持不變。沒有名字劫持。沒有供應鏈注入。
麻省理工學院的許可證本質上允許你「用它做任何你想做的事」。沒有任何附加條件。
我們到了。一個簡單的日誌？
以上是簡單的 Python 日誌記錄 - 以及關於依賴項、信任和複製/貼上程式碼的題外話的詳細內容。更多資訊請關注PHP中文網其他相關文章！
