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 ?
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
Et vous fondez votre jugement de lourdeur sur quels faits ? Le module logging n'a jamais ralenti mes softs ...
f
Do Re Mi chel La Si Do wrote:
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.
Franchement, si l'anglais est un défaut pour une documentation, vous
passez à coté de 80% de ce qui est interessant dans le monde informatique ...
Les ressources françaises ne sont pas énormes (bien qu'existante !), il est impossible de tout traduire tant le dynamisme de la communauté python (et les autres) passe par un moyen de se comprendre internationalement.
Et, c'est étrange, il n'y a rien de plus efficace que l'anglais pour parler à un mexicain, un indien, un japonais, un suédois ... et ainsi faire avancer le langage et ses modules.
Sinon, quels sont les autres défauts de cette documentation ? Le trop d'exemple ? Une documentation de référence n'est que rarement un tutoriel ... Pour les exemples, le cookbook est une mine d'or. D'ailleurs, sur le module logging :
Vous me direz, c'est en anglais, c'est un gros défaut ...
Do Re Mi chel La Si Do wrote:
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.
Franchement, si l'anglais est un défaut pour une documentation, vous
passez à coté de 80% de ce qui est interessant dans le monde
informatique ...
Les ressources françaises ne sont pas énormes (bien qu'existante !), il
est impossible de tout traduire tant le dynamisme de la communauté
python (et les autres) passe par un moyen de se comprendre
internationalement.
Et, c'est étrange, il n'y a rien de plus efficace que l'anglais pour
parler à un mexicain, un indien, un japonais, un suédois ... et ainsi
faire avancer le langage et ses modules.
Sinon, quels sont les autres défauts de cette documentation ? Le trop
d'exemple ? Une documentation de référence n'est que rarement un
tutoriel ... Pour les exemples, le cookbook est une mine d'or.
D'ailleurs, sur 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.
Franchement, si l'anglais est un défaut pour une documentation, vous
passez à coté de 80% de ce qui est interessant dans le monde informatique ...
Les ressources françaises ne sont pas énormes (bien qu'existante !), il est impossible de tout traduire tant le dynamisme de la communauté python (et les autres) passe par un moyen de se comprendre internationalement.
Et, c'est étrange, il n'y a rien de plus efficace que l'anglais pour parler à un mexicain, un indien, un japonais, un suédois ... et ainsi faire avancer le langage et ses modules.
Sinon, quels sont les autres défauts de cette documentation ? Le trop d'exemple ? Une documentation de référence n'est que rarement un tutoriel ... Pour les exemples, le cookbook est une mine d'or. D'ailleurs, sur le module logging :
Vous me direz, c'est en anglais, c'est un gros défaut ...
Laurent Coustet
Do Re Mi chel La Si Do wrote:
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Quel intéret de poster ce type de messages ? Juste pour le plaisir de critiquer ?
Personellement, j'ai aussi fais pas mal de système de logging, et je peux dire qu'avant de percevoir l'efficacitée du système de logging python, je n'utilisais pas le log de la même manière. Je suis vraiment ravi de pouvoir changer le format de tous mes logs en 1 seule ligne, d'envoyer par mail, par syslog, et dans plusieurs fichiers, sur des formats différents en quelques lignes...
Merci python, et merci pour la réponse sur textwrap qui me conviens parfaitement. Votre réponse n'apporte absoluement rien, elle n'a vraiment rien a faire sur ce forum de discution, postez donc sur fr.comp.troll.
-- Laurent Coustet
Do Re Mi chel La Si Do wrote:
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Quel intéret de poster ce type de messages ? Juste pour le plaisir de
critiquer ?
Personellement, j'ai aussi fais pas mal de système de logging, et je
peux dire qu'avant de percevoir l'efficacitée du système de logging
python, je n'utilisais pas le log de la même manière. Je suis vraiment
ravi de pouvoir changer le format de tous mes logs en 1 seule ligne,
d'envoyer par mail, par syslog, et dans plusieurs fichiers, sur des
formats différents en quelques lignes...
Merci python, et merci pour la réponse sur textwrap qui me conviens
parfaitement. Votre réponse n'apporte absoluement rien, elle n'a
vraiment rien a faire sur ce forum de discution, postez donc sur
fr.comp.troll.
Merci de l'info. C'est bien ce que je craignais : un module un peu lourd.
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Quel intéret de poster ce type de messages ? Juste pour le plaisir de critiquer ?
Personellement, j'ai aussi fais pas mal de système de logging, et je peux dire qu'avant de percevoir l'efficacitée du système de logging python, je n'utilisais pas le log de la même manière. Je suis vraiment ravi de pouvoir changer le format de tous mes logs en 1 seule ligne, d'envoyer par mail, par syslog, et dans plusieurs fichiers, sur des formats différents en quelques lignes...
Merci python, et merci pour la réponse sur textwrap qui me conviens parfaitement. Votre réponse n'apporte absoluement rien, elle n'a vraiment rien a faire sur ce forum de discution, postez donc sur fr.comp.troll.
-- Laurent Coustet
Eric Masson
Laurent Coustet writes:
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Euh, non rien...
Éric Masson
-- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Euh, non rien...
Éric Masson
--
"Les neu^H^H^H connectés"?? Peux-tu nous en dire plus.
Autant dire que l'on veut muselé les minorités sous des prétexte
falacieux avec des méthodes dignes de la Française des jeux!!
-+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
Je ne comprends vraiment pas pourquoi vous postez un tel message ?
Euh, non rien...
Éric Masson
-- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
Do Re Mi chel La Si Do
Bonsoir !
Effectivement, mon message est teinté de négativisme, et n'apporte rien.
La raison est psychologique : j'ai tenté d'utiliser le module "gettext", pour internationaliser des scripts. Après pas mal de temps passé à galérer, j'ai trouvé beaucoup plus simple, facile, et efficace de faire mon propre système de messages ; je n'ai gardé que le nom de la fonction : _( ) Pour des raisons proches, je suis en train de reconsidérer epydoc, et, même, les docstrings.
De cette expérience malheureuse, j'en ai retiré l'enseignement que les modules tout prêts ne sont pas toujours adaptés à un besoin précis. D'ailleurs, je suis partisan des développements spécifiques, versus les progiciels.
Voilà l'explication du message. Mais excusez-moi d'avoir troublé, inutilement, votre thread.
@-salutations
Michel Claveau
Bonsoir !
Effectivement, mon message est teinté de négativisme, et n'apporte rien.
La raison est psychologique : j'ai tenté d'utiliser le module "gettext",
pour internationaliser des scripts. Après pas mal de temps passé à galérer,
j'ai trouvé beaucoup plus simple, facile, et efficace de faire mon propre
système de messages ; je n'ai gardé que le nom de la fonction : _( )
Pour des raisons proches, je suis en train de reconsidérer epydoc, et, même,
les docstrings.
De cette expérience malheureuse, j'en ai retiré l'enseignement que les
modules tout prêts ne sont pas toujours adaptés à un besoin précis.
D'ailleurs, je suis partisan des développements spécifiques, versus les
progiciels.
Voilà l'explication du message. Mais excusez-moi d'avoir troublé,
inutilement, votre thread.
Effectivement, mon message est teinté de négativisme, et n'apporte rien.
La raison est psychologique : j'ai tenté d'utiliser le module "gettext", pour internationaliser des scripts. Après pas mal de temps passé à galérer, j'ai trouvé beaucoup plus simple, facile, et efficace de faire mon propre système de messages ; je n'ai gardé que le nom de la fonction : _( ) Pour des raisons proches, je suis en train de reconsidérer epydoc, et, même, les docstrings.
De cette expérience malheureuse, j'en ai retiré l'enseignement que les modules tout prêts ne sont pas toujours adaptés à un besoin précis. D'ailleurs, je suis partisan des développements spécifiques, versus les progiciels.
Voilà l'explication du message. Mais excusez-moi d'avoir troublé, inutilement, votre thread.
@-salutations
Michel Claveau
mutah
merci de votre mea culpa de troll :))
Je fais un beau hors-sujet pour le clore.
Concernant la manière d'aborder la réponse à des besoins précis, je pense que le sens du métier de développeur consiste justement à cerner les capacités des modules "tout prêts" de manière à les intégrer de façon à accomplir le fameux besoin.
De mon expérience, et c'est d'autant plus vérifié avec le langage python, on ne fait qu'assembler des composants, le code est comme un mortier entre des bibliothèques d'objets réutilisables. Cela s'appelle l'adaptation.
Python est un langage "glue", qui permet d'accomplir de tels mécanismes, par exemple utiliser des librairies faites en C ou en C++.
Parfois, des modules remplissent complètement les besoins. Parfois, on se trouve face à des situations inextricables face à des dépendances buggées. On exige toujours quelque chose d'un composant qu'on utilise. Intégrer un module dans une application implique un savoir faire dans l'utilisation de ce module, et avant tout dans l'évaluation de l'adéquation aux besoins.
L'experience arrive après qu'on en ait eu besoin. C'est cruel, mais tel est la voie du développeur à fortiori dans le développement d'application à partir de composants open-source.
Mais il ne faut pas, comme vous le soulignez, adopter une attitude négative. Il y a très souvent moyen de choisir des versions stables, ou de s'arranger suffisemment pour contourner des bugs.
Il faut parfois faire le grand écart, mais se plaindre de ce qui est offert par la communauté est, à mon avis, déplacé. Si un module semble ne pas marcher, il faut faire marcher les réseaux des communautés d'utilisateur pour trouver des solutions ou des alternatives : c'est le sens même de cet endroit.
L'entraide, l'échange d'expertise, c'est ce qui fait avancer le mouvement. Cela nécessite un investissement, dont la connaissance de l'anglais technique et l'utilisation des ressources documentaires font parties pour pouvoir en tirer une satisfaction au quotidien.
Dans le monde du logiciel libre, c'est incontournable. Si l'on a envie de se plaindre, on le paie avec un logiciel proprio avec lequel on a un numéro de hotline pour gueuler. mais là, comme dirait l'autre, c'est le coté obscur de la force :o)
Salutations
merci de votre mea culpa de troll :))
Je fais un beau hors-sujet pour le clore.
Concernant la manière d'aborder la réponse à des besoins précis, je
pense que le sens du métier de développeur consiste justement à
cerner les capacités des modules "tout prêts" de manière à les
intégrer de façon à accomplir le fameux besoin.
De mon expérience, et c'est d'autant plus vérifié avec le langage
python, on ne fait qu'assembler des composants, le code est comme un
mortier entre des bibliothèques d'objets réutilisables. Cela
s'appelle l'adaptation.
Python est un langage "glue", qui permet d'accomplir de tels
mécanismes, par exemple utiliser des librairies faites en C ou en C++.
Parfois, des modules remplissent complètement les besoins. Parfois, on
se trouve face à des situations inextricables face à des dépendances
buggées. On exige toujours quelque chose d'un composant qu'on utilise.
Intégrer un module dans une application implique un savoir faire dans
l'utilisation de ce module, et avant tout dans l'évaluation de
l'adéquation aux besoins.
L'experience arrive après qu'on en ait eu besoin. C'est cruel, mais
tel est la voie du développeur à fortiori dans le développement
d'application à partir de composants open-source.
Mais il ne faut pas, comme vous le soulignez, adopter une attitude
négative. Il y a très souvent moyen de choisir des versions stables,
ou de s'arranger suffisemment pour contourner des bugs.
Il faut parfois faire le grand écart, mais se plaindre de ce qui est
offert par la communauté est, à mon avis, déplacé. Si un module
semble ne pas marcher, il faut faire marcher les réseaux des
communautés d'utilisateur pour trouver des solutions ou des
alternatives : c'est le sens même de cet endroit.
L'entraide, l'échange d'expertise, c'est ce qui fait avancer le
mouvement. Cela nécessite un investissement, dont la connaissance de
l'anglais technique et l'utilisation des ressources documentaires font
parties pour pouvoir en tirer une satisfaction au quotidien.
Dans le monde du logiciel libre, c'est incontournable. Si l'on a envie
de se plaindre, on le paie avec un logiciel proprio avec lequel on a un
numéro de hotline pour gueuler. mais là, comme dirait l'autre, c'est
le coté obscur de la force :o)
Concernant la manière d'aborder la réponse à des besoins précis, je pense que le sens du métier de développeur consiste justement à cerner les capacités des modules "tout prêts" de manière à les intégrer de façon à accomplir le fameux besoin.
De mon expérience, et c'est d'autant plus vérifié avec le langage python, on ne fait qu'assembler des composants, le code est comme un mortier entre des bibliothèques d'objets réutilisables. Cela s'appelle l'adaptation.
Python est un langage "glue", qui permet d'accomplir de tels mécanismes, par exemple utiliser des librairies faites en C ou en C++.
Parfois, des modules remplissent complètement les besoins. Parfois, on se trouve face à des situations inextricables face à des dépendances buggées. On exige toujours quelque chose d'un composant qu'on utilise. Intégrer un module dans une application implique un savoir faire dans l'utilisation de ce module, et avant tout dans l'évaluation de l'adéquation aux besoins.
L'experience arrive après qu'on en ait eu besoin. C'est cruel, mais tel est la voie du développeur à fortiori dans le développement d'application à partir de composants open-source.
Mais il ne faut pas, comme vous le soulignez, adopter une attitude négative. Il y a très souvent moyen de choisir des versions stables, ou de s'arranger suffisemment pour contourner des bugs.
Il faut parfois faire le grand écart, mais se plaindre de ce qui est offert par la communauté est, à mon avis, déplacé. Si un module semble ne pas marcher, il faut faire marcher les réseaux des communautés d'utilisateur pour trouver des solutions ou des alternatives : c'est le sens même de cet endroit.
L'entraide, l'échange d'expertise, c'est ce qui fait avancer le mouvement. Cela nécessite un investissement, dont la connaissance de l'anglais technique et l'utilisation des ressources documentaires font parties pour pouvoir en tirer une satisfaction au quotidien.
Dans le monde du logiciel libre, c'est incontournable. Si l'on a envie de se plaindre, on le paie avec un logiciel proprio avec lequel on a un numéro de hotline pour gueuler. mais là, comme dirait l'autre, c'est le coté obscur de la force :o)
Salutations
Do Re Mi chel La Si Do
Bonsoir !
Rapidement, car je ne veux pas provoquer une discussion sans fin : - ne confondez pas message inutile, message hors sujet, et troll - une longue expérience du développement m'ont amené à avoir des positions très différentes des vôtres.
@-salutations
Michel Claveau
Bonsoir !
Rapidement, car je ne veux pas provoquer une discussion sans fin :
- ne confondez pas message inutile, message hors sujet, et troll
- une longue expérience du développement m'ont amené à avoir des
positions très différentes des vôtres.
Rapidement, car je ne veux pas provoquer une discussion sans fin : - ne confondez pas message inutile, message hors sujet, et troll - une longue expérience du développement m'ont amené à avoir des positions très différentes des vôtres.
@-salutations
Michel Claveau
f
Do Re Mi chel La Si Do wrote:
- ne confondez pas message inutile, message hors sujet, et troll
un troll est un message inutile un hors-sujet est souvent inutile un message inutile est ... un message inutile :))
- une longue expérience du développement m'ont amené à avoir des positions très différentes des vôtres.
Tout à fait. A lire votre site, vous avez une grande expérience dans le développement sous plateforme windows, où vous avez intégré beaucoup de composants propriétaires. Je comprend mieux votre réticence à l'anglais technique, car je sais que ces produits souvent assez bien documentés en français.
L'open-source et à fortiori le logiciel libre, c'est souvent bien plus minimaliste, le rapport à l'utilisation des composants est définivement différent, obligeant (malheureusement) les développeurs à être débrouillards, à ne pas hésiter à ouvrir les sources et à fouiller le web sans relâche pour trouver la personne qui a le même problème.
A expérience différente, position différente, mais vive la diversité des points de vue !
Do Re Mi chel La Si Do wrote:
- ne confondez pas message inutile, message hors sujet, et troll
un troll est un message inutile
un hors-sujet est souvent inutile
un message inutile est ... un message inutile :))
- une longue expérience du développement m'ont amené à avoir des
positions très différentes des vôtres.
Tout à fait. A lire votre site, vous avez une grande expérience dans le
développement sous plateforme windows, où vous avez intégré beaucoup de
composants propriétaires. Je comprend mieux votre réticence à l'anglais
technique, car je sais que ces produits souvent assez bien documentés en
français.
L'open-source et à fortiori le logiciel libre, c'est souvent bien plus
minimaliste, le rapport à l'utilisation des composants est définivement
différent, obligeant (malheureusement) les développeurs à être
débrouillards, à ne pas hésiter à ouvrir les sources et à fouiller le
web sans relâche pour trouver la personne qui a le même problème.
A expérience différente, position différente, mais vive la diversité des
points de vue !
- ne confondez pas message inutile, message hors sujet, et troll
un troll est un message inutile un hors-sujet est souvent inutile un message inutile est ... un message inutile :))
- une longue expérience du développement m'ont amené à avoir des positions très différentes des vôtres.
Tout à fait. A lire votre site, vous avez une grande expérience dans le développement sous plateforme windows, où vous avez intégré beaucoup de composants propriétaires. Je comprend mieux votre réticence à l'anglais technique, car je sais que ces produits souvent assez bien documentés en français.
L'open-source et à fortiori le logiciel libre, c'est souvent bien plus minimaliste, le rapport à l'utilisation des composants est définivement différent, obligeant (malheureusement) les développeurs à être débrouillards, à ne pas hésiter à ouvrir les sources et à fouiller le web sans relâche pour trouver la personne qui a le même problème.
A expérience différente, position différente, mais vive la diversité des points de vue !
