konzept für's logging

[okular]

Hallo erstmal, liebe Community,

ich bin heute das erste mal hier. Kurz zu mir: Bin seit einigen Jahren Linux-Administrator und habe bin nun in der Situation, Software schreiben zu müssen - in Python natürlich.

Zu meiner Frage: Ich habe einige module, die klassen implementieren. So, und nun möchte ich genau eine logging-klasse haben, von der es aber nur eine Instanz geben sollte. Wie würdet ihr das machen? Also aus jedem der module können beliebig viele log-requests kommen, die aber alle an eine methode genau einer klasse übergeben werden sollen.

Hat einer ein grobes konzept für sowas? Ich möchte also nicht, dass jedes modul für sich loggt...

Hoffe, ich habe mich verständlich machen können...?

Schöne Grüße,
Okular (aus hannover)

[sparrow]

http://docs.python.org/library/logging.html

http://docs.python.org/howto/logging-cookbook.html

Grüße aus 60 km südlich von Hannover

[okular]

Hey, super! Wird mir helfen, wie's aussieht.

Danke!

[okular]

Puhhh, das ist sogar exakt das Richtige...

[Leonidas]

Und wenns weniger blöde API haben soll gibt es auch eine Lösung.

[lunar]

@Leonidas Die letzte Änderung vor acht Monaten, seit zwei Jahren steht unten „still under development“, … so einer Bibliothek vertraut man doch gerne so etwas Wichtiges wie Logging an.

[Leonidas]

Ist ja nicht so dass sich im Bereich Logging so viel ändert, dass die Lib ständig angepasst werden müsste.

[snafu]

@Leonidas: Naja, "still under development" impliziert, dass noch viele Änderungen an der API gemacht werden könnten und möglicherweise nicht mal einer konkreten Versionsnummer zugeordnet werden können. Zumindest wenn man sein Programm weiterreicht oder auf verschiedenen Rechnern verwenden möchte, kann es theoretisch dazu kommen, dass später einmal eine Version der verwendeten Logging-Bibliothek nachgeladen wird, die nicht mehr kompatibel zu der erwarteten Schnittstelle ist und unter Umständen das ganze Programm oder halt den Teil des Loggings zerstört. Da müsste man also immer die verwendete Version mitliefern, um ganz sicher zu gehen. Wäre zumindest in meinen Augen das, was mir Bauchschmerzen bereiten würde.

Dass die Entwicklung an einem Projekt mal etwas länger ruht, finde ich persönlich auch nicht so dramatisch. Solange wir von einigen Monaten und nicht von 5 Jahren spechen, sehe ich da wenig Probleme drin. Nur dass das "Development" inzwischen schon 2 Jahre da steht, könnte allmählich Zweifel aufkommen lassen, inwiefern das Projekt wirklich ausgereift ist. Die Frage ist halt, was der Entwickler unter "Development" versteht. Je nach Sichtweise könnte man dann auch sagen, dass man eine Software erst ab ihrem "1.0"-Release nutzen möchte, obwohl es - wie viele Beispiele zeigen - schon weitaus eher möglich ist, abhängig von der Release/Kompatibilitäts-Politik des Entwicklers.

[lunar]

@Leonidas Tja, offenbar ändert sich doch so viel, dass die Bibliothek nach zwei Jahren(!) „still under development“ ist, und kein stabiles Release hervorgebracht hat…

[BlackJack]

Versionsnummern kleiner 1.0 sind aller Erfahrung nach ja nicht wirklich ein Problem, aber so Sätze wie `Currently logbook is an alpha version and should be considered a developer preview.` in der Dokumentation laden halt nicht wirklich dazu ein die Bibliothek ernsthaft einzusetzen.

[Hyperion]

Man müsste eben mal gucken, ob die von Pocoo diese Lib aktuell selber häufig einsetzen. Wenn ja, könnte man zumindest ableiten, dass sie selber die API wohl als stabil ansehen...