J'utilise le module logging de python 2.3. Cela fonctionne parfaitement,
sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas,
les lignes sont tronquées, et non reportées sur une ligne suivante par
exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs
lignes ?
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement, sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas, les lignes sont tronquées, et non reportées sur une ligne suivante par exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs lignes ?
une suggestion : import textwrap envoyer au module logging textwrap.fill(ligneTresLongue, width)
Merci,
-- Théorie d'une pile "LIFO" : Jésus dit : les premiers seront les derniers, et les derniers seront les premiers. Mathieu 20-16
Bonjour,
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement,
sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas,
les lignes sont tronquées, et non reportées sur une ligne suivante par
exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs
lignes ?
une suggestion :
import textwrap
envoyer au module logging textwrap.fill(ligneTresLongue, width)
Merci,
--
Théorie d'une pile "LIFO" :
Jésus dit : les premiers seront les derniers, et les derniers seront les
premiers. Mathieu 20-16
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement, sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas, les lignes sont tronquées, et non reportées sur une ligne suivante par exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs lignes ?
une suggestion : import textwrap envoyer au module logging textwrap.fill(ligneTresLongue, width)
Merci,
-- Théorie d'une pile "LIFO" : Jésus dit : les premiers seront les derniers, et les derniers seront les premiers. Mathieu 20-16
Do Re Mi chel La Si Do
Bonjour !
J'allais écrire une bêtise. Heureusement, j'ai vérifié d'abord. Donc, je n'ai pas posté le message en question. Donc, le présent message est peu utile.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
@-salutations
Michel Claveau
Bonjour !
J'allais écrire une bêtise. Heureusement, j'ai vérifié d'abord.
Donc, je n'ai pas posté le message en question.
Donc, le présent message est peu utile.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
J'allais écrire une bêtise. Heureusement, j'ai vérifié d'abord. Donc, je n'ai pas posté le message en question. Donc, le présent message est peu utile.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
@-salutations
Michel Claveau
F. Petitjean
Bonjour !
J'allais écrire une bêtise.
Cela ne vous ressemble pas et cela aurait été "ballot" :-)
Heureusement, j'ai vérifié d'abord. Donc, je n'ai pas posté le message en question.
C'est gentil.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer les lignes très très longues :-) Blague à part, c'est une usine à gaz, inspirée d'un module java pour générer un fichier journal avec un filtrage des messages selon une classification du genre info, debug, warning, error, fatal ,..
@-salutations
Michel Claveau
Bonjour !
J'allais écrire une bêtise.
Cela ne vous ressemble pas et cela aurait été "ballot" :-)
Heureusement, j'ai vérifié d'abord.
Donc, je n'ai pas posté le message en question.
C'est gentil.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer
les lignes très très longues :-) Blague à part, c'est une usine à gaz,
inspirée d'un module java pour générer un fichier journal avec un
filtrage des messages selon une classification du genre info, debug,
warning, error, fatal ,..
Cela ne vous ressemble pas et cela aurait été "ballot" :-)
Heureusement, j'ai vérifié d'abord. Donc, je n'ai pas posté le message en question.
C'est gentil.
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer les lignes très très longues :-) Blague à part, c'est une usine à gaz, inspirée d'un module java pour générer un fichier journal avec un filtrage des messages selon une classification du genre info, debug, warning, error, fatal ,..
@-salutations
Michel Claveau
f
F. Petitjean wrote:
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer les lignes très très longues :-) Blague à part, c'est une usine à gaz, inspirée d'un module java pour générer un fichier journal avec un filtrage des messages selon une classification du genre info, debug, warning, error, fatal ,..
Blague à part : "usine à gaz" ???????????
Vous êtes-vous posé un jour la problématique du logging ? Si c'était si simple, ce module n'aurait pas la 'complexité' apparente qu'il a. Il est certes âpre à aborder la première fois, mais ses capacités permettent un raffinement qui, une fois en production, permettent une grande maitrise de la traçabilité de l'application, ce qui sauve des heures à rechercher la petite bête.
L'inspiration des développements java est loin d'être un aspect négatif quand on voit l'apport essentiel de la communauté java aux pratiques des développements objets. J'ai implémenté un nombre conséquent de design patterns issus de java en python. Le savoir-faire objet est universel et ne dépend que très peu des langages.
Merci python d'avoir ce module si intelligement pensé, et d'avoir pris le meilleur là où il se trouvait en terme d'architecture !
François
F. Petitjean wrote:
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer
les lignes très très longues :-) Blague à part, c'est une usine à gaz,
inspirée d'un module java pour générer un fichier journal avec un
filtrage des messages selon une classification du genre info, debug,
warning, error, fatal ,..
Blague à part : "usine à gaz" ???????????
Vous êtes-vous posé un jour la problématique du logging ? Si c'était si
simple, ce module n'aurait pas la 'complexité' apparente qu'il a. Il est
certes âpre à aborder la première fois, mais ses capacités permettent un
raffinement qui, une fois en production, permettent une grande maitrise
de la traçabilité de l'application, ce qui sauve des heures à rechercher
la petite bête.
L'inspiration des développements java est loin d'être un aspect négatif
quand on voit l'apport essentiel de la communauté java aux pratiques des
développements objets. J'ai implémenté un nombre conséquent de design
patterns issus de java en python. Le savoir-faire objet est universel et
ne dépend que très peu des langages.
Merci python d'avoir ce module si intelligement pensé, et d'avoir pris
le meilleur là où il se trouvait en terme d'architecture !
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
Pourtant, à la lecture du message, c'est clair : cela sert à tronquer les lignes très très longues :-) Blague à part, c'est une usine à gaz, inspirée d'un module java pour générer un fichier journal avec un filtrage des messages selon une classification du genre info, debug, warning, error, fatal ,..
Blague à part : "usine à gaz" ???????????
Vous êtes-vous posé un jour la problématique du logging ? Si c'était si simple, ce module n'aurait pas la 'complexité' apparente qu'il a. Il est certes âpre à aborder la première fois, mais ses capacités permettent un raffinement qui, une fois en production, permettent une grande maitrise de la traçabilité de l'application, ce qui sauve des heures à rechercher la petite bête.
L'inspiration des développements java est loin d'être un aspect négatif quand on voit l'apport essentiel de la communauté java aux pratiques des développements objets. J'ai implémenté un nombre conséquent de design patterns issus de java en python. Le savoir-faire objet est universel et ne dépend que très peu des langages.
Merci python d'avoir ce module si intelligement pensé, et d'avoir pris le meilleur là où il se trouvait en terme d'architecture !
François
f
Do Re Mi chel La Si Do wrote:
Du coup, il me reste plus qu'à demander : à quoi sert le module "logging" ?
J'avais déjà regardé cette doc. Mais elle a plusieurs défauts, dont un des principaux est de na pas être en français ; ce qui, pour moi, est péjoratif.
@-salutations
Michel Claveau
Bonsoir !
J'avais déjà regardé cette doc. Mais elle a plusieurs défauts, dont un des
principaux est de na pas être en français ; ce qui, pour moi, est péjoratif.
J'avais déjà regardé cette doc. Mais elle a plusieurs défauts, dont un des principaux est de na pas être en français ; ce qui, pour moi, est péjoratif.
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
@-salutations
Michel Claveau
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Bonsoir !
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à partager l'avis de F. Petitjean.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça, je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
@-salutations
Michel Claveau
Bonsoir !
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à
partager l'avis de F. Petitjean.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de
temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par
contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça,
je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à partager l'avis de F. Petitjean.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça, je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
@-salutations
Michel Claveau
Alex Marandon
On 2005-05-23, Do Re Mi chel La Si Do wrote:
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à partager l'avis de F. Petitjean.
Honnêtement, je ne vois pas ce que vous trouvez de si compliqué à ce module, mais il est vrai que je n'ai pas trop de problèmes pour lire l'anglais technique.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça, je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
L'intérêt de ce module est AMHA, en plus d'une implémentation basique, de fournir une API d'après une analyse déja faite de la problématique du logging. Après tu peux facilement spécialiser ses composants en fonctions de tes besoins spécifiques. Le code est assez clair et bien commenté pour ça. Pour ma part je l'utilise pour insérer les messages dépassant une certaine criticité dans une table de SGBD consultable par les utilisateurs via une IHM. Avec une seule instruction dans le code client, les messages sont envoyés vers la sortie d'erreur standard, le syslog, la base de données et par mail, chaque media étant configuré de manière centralisé pour accepter les messages d'un certains niveau de criticité.
Pour juger de sa qualité, il faut aussi prendre en compte le fait que cette API est un standard de facto, le jour ou tu auras à coder en Java, Perl, C++ ou que sais-je, tu trouveras des modules qui l'implémentent. C'est un peu au logging ce que DOM et SAX sont au XML, une fois qu'on a compris le principe, il est aisé de le transposer dans différents environnements.
-- Alex
On 2005-05-23, Do Re Mi chel La Si Do <enleverlesO.OmcO@OmclaveauO.com> wrote:
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à
partager l'avis de F. Petitjean.
Honnêtement, je ne vois pas ce que vous trouvez de si compliqué à ce
module, mais il est vrai que je n'ai pas trop de problèmes pour lire
l'anglais technique.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de
temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par
contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça,
je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
L'intérêt de ce module est AMHA, en plus d'une implémentation basique,
de fournir une API d'après une analyse déja faite de la problématique du
logging. Après tu peux facilement spécialiser ses composants en
fonctions de tes besoins spécifiques. Le code est assez clair et bien
commenté pour ça. Pour ma part je l'utilise pour insérer les messages
dépassant une certaine criticité dans une table de SGBD consultable par
les utilisateurs via une IHM. Avec une seule instruction dans le code
client, les messages sont envoyés vers la sortie d'erreur standard, le
syslog, la base de données et par mail, chaque media étant configuré de
manière centralisé pour accepter les messages d'un certains niveau de
criticité.
Pour juger de sa qualité, il faut aussi prendre en compte le fait que
cette API est un standard de facto, le jour ou tu auras à coder en Java,
Perl, C++ ou que sais-je, tu trouveras des modules qui l'implémentent.
C'est un peu au logging ce que DOM et SAX sont au XML, une fois qu'on a
compris le principe, il est aisé de le transposer dans différents
environnements.
J'ai jeté un oeil à la doc (malgré l'anglais...), et j'aurais tendance à partager l'avis de F. Petitjean.
Honnêtement, je ne vois pas ce que vous trouvez de si compliqué à ce module, mais il est vrai que je n'ai pas trop de problèmes pour lire l'anglais technique.
Des "journaux", de traitements, d'alertes, d'erreurs, etc. j'en fais de temps en temps. Et je n'ai jamais eu besoin de toutes ces méthodes. Par contre, j'ai souvent besoin de gérer du verrouillage optimiste, et, pour ça, je n'ai rien vu dans ce module. Heureusement, que les SGBD existent...
L'intérêt de ce module est AMHA, en plus d'une implémentation basique, de fournir une API d'après une analyse déja faite de la problématique du logging. Après tu peux facilement spécialiser ses composants en fonctions de tes besoins spécifiques. Le code est assez clair et bien commenté pour ça. Pour ma part je l'utilise pour insérer les messages dépassant une certaine criticité dans une table de SGBD consultable par les utilisateurs via une IHM. Avec une seule instruction dans le code client, les messages sont envoyés vers la sortie d'erreur standard, le syslog, la base de données et par mail, chaque media étant configuré de manière centralisé pour accepter les messages d'un certains niveau de criticité.
Pour juger de sa qualité, il faut aussi prendre en compte le fait que cette API est un standard de facto, le jour ou tu auras à coder en Java, Perl, C++ ou que sais-je, tu trouveras des modules qui l'implémentent. C'est un peu au logging ce que DOM et SAX sont au XML, une fois qu'on a compris le principe, il est aisé de le transposer dans différents environnements.
-- Alex
Alex Marandon
On 2005-05-23, Laurent Coustet wrote:
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement, sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas, les lignes sont tronquées, et non reportées sur une ligne suivante par exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs lignes ?
Salut Laurent,
Je viens de jeter un coup d'oeil rapide au code du module et je n'ai pas vu la cause de ce problème. Sinon tu peux effectivement définir ton propre handler héritant d'un existant et redéfinir ce qui est nécessaire. A priori ce serait la méthode format() qu'il faudrait redéfinir pour y faire ton split.
HTH
-- Alex
On 2005-05-23, Laurent Coustet <laurent.coustet@clarisys.fr> wrote:
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement,
sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas,
les lignes sont tronquées, et non reportées sur une ligne suivante par
exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs
lignes ?
Salut Laurent,
Je viens de jeter un coup d'oeil rapide au code du module et je n'ai pas
vu la cause de ce problème. Sinon tu peux effectivement définir ton
propre handler héritant d'un existant et redéfinir ce qui est nécessaire.
A priori ce serait la méthode format() qu'il faudrait redéfinir pour y
faire ton split.
J'utilise le module logging de python 2.3. Cela fonctionne parfaitement, sauf si j'essaye de logger des lignes tres tres longues. Dans ce cas, les lignes sont tronquées, et non reportées sur une ligne suivante par exemple.
Je ne sais pas comment procéder au mieux avec le module logging ?
Implémenter une methode permettant de "spliter" mon message en plusieurs lignes ?
Salut Laurent,
Je viens de jeter un coup d'oeil rapide au code du module et je n'ai pas vu la cause de ce problème. Sinon tu peux effectivement définir ton propre handler héritant d'un existant et redéfinir ce qui est nécessaire. A priori ce serait la méthode format() qu'il faudrait redéfinir pour y faire ton split.
