Pour les applis, c'est du gui wxpython essentiellement. Je suis en train de découvrir pdb.
Merci Dominique
utopia
a écrit :
Bonjour, J'en ai marre de faire des print... ;-)
------------------------------------- source : Comment ca marche . fr http://www.commentcamarche.net/forum/affich-1245586-python-module-logging ------------------------------------ Quand vous avez une appli avec beaucoup de classes ou de threads, il est parfois difficile de voir ce qui se passe. Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre application.
exemple: monappli monappli.database monappli.database.updateUsers monappli.mail etc.
Ces logs sont accessible de n'importe où dans l'application. Chacune de vos classes/threads peut loguer dans un de ces logs (très simple: log = logger.getLogger('monappli.database') et puis log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug, info, warning,error, exception, critical...) Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs générés dans toute l'application. Ou bien se brancher uniquement sur 'monappli.database' pour ne voir que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les warning ou jusqu'au détail (debug). Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bie n aller sur une application en production et passer en mode 'debug' pour voir ce qui se passe sans interrompre l'application. (Ils ont même prévu un socket serveur pour demander en live à l'appli de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut pluguer un handler qui va automatiquement faire des actions: - afficher à l'écran - écrire dans un fichier - écrire dans un fichier (avec log rotatif automatique) - envoyer à un syslog - écrire dans l'eventlog de Windows - envoyer sur un socket - envoyer une trame UDP - envoyer une requête HTTP - envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de filtres pour ne récupérer que les évènements qui vous intéressent . On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
MyDomDom@gmail.com a écrit :
Bonjour,
J'en ai marre de faire des print... ;-)
-------------------------------------
source :
Comment ca marche . fr
http://www.commentcamarche.net/forum/affich-1245586-python-module-logging
------------------------------------
Quand vous avez une appli avec beaucoup de classes ou de threads, il
est parfois difficile de voir ce qui se passe.
Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre
application.
exemple:
monappli
monappli.database
monappli.database.updateUsers
monappli.mail
etc.
Ces logs sont accessible de n'importe où dans l'application.
Chacune de vos classes/threads peut loguer dans un de ces logs
(très simple:
log = logger.getLogger('monappli.database') et puis
log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug,
info, warning,error, exception, critical...)
Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour
écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs
générés dans toute l'application.
Ou bien se brancher uniquement sur 'monappli.database' pour ne voir
que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les
warning ou jusqu'au détail (debug).
Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bie n
aller sur une application en production et passer en mode 'debug' pour
voir ce qui se passe sans interrompre l'application.
(Ils ont même prévu un socket serveur pour demander en live à l'appli
de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut
pluguer un handler qui va automatiquement faire des actions:
- afficher à l'écran
- écrire dans un fichier
- écrire dans un fichier (avec log rotatif automatique)
- envoyer à un syslog
- écrire dans l'eventlog de Windows
- envoyer sur un socket
- envoyer une trame UDP
- envoyer une requête HTTP
- envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de
filtres pour ne récupérer que les évènements qui vous intéressent .
On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
------------------------------------- source : Comment ca marche . fr http://www.commentcamarche.net/forum/affich-1245586-python-module-logging ------------------------------------ Quand vous avez une appli avec beaucoup de classes ou de threads, il est parfois difficile de voir ce qui se passe. Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre application.
exemple: monappli monappli.database monappli.database.updateUsers monappli.mail etc.
Ces logs sont accessible de n'importe où dans l'application. Chacune de vos classes/threads peut loguer dans un de ces logs (très simple: log = logger.getLogger('monappli.database') et puis log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug, info, warning,error, exception, critical...) Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs générés dans toute l'application. Ou bien se brancher uniquement sur 'monappli.database' pour ne voir que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les warning ou jusqu'au détail (debug). Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bie n aller sur une application en production et passer en mode 'debug' pour voir ce qui se passe sans interrompre l'application. (Ils ont même prévu un socket serveur pour demander en live à l'appli de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut pluguer un handler qui va automatiquement faire des actions: - afficher à l'écran - écrire dans un fichier - écrire dans un fichier (avec log rotatif automatique) - envoyer à un syslog - écrire dans l'eventlog de Windows - envoyer sur un socket - envoyer une trame UDP - envoyer une requête HTTP - envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de filtres pour ne récupérer que les évènements qui vous intéressent . On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
NicolasP
utopia a écrit :
a écrit :
Bonjour, J'en ai marre de faire des print... ;-)
------------------------------------- source : Comment ca marche . fr http://www.commentcamarche.net/forum/affich-1245586-python-module-logging ------------------------------------ Quand vous avez une appli avec beaucoup de classes ou de threads, il est parfois difficile de voir ce qui se passe. Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre application.
exemple: monappli monappli.database monappli.database.updateUsers monappli.mail etc.
Ces logs sont accessible de n'importe où dans l'application. Chacune de vos classes/threads peut loguer dans un de ces logs (très simple: log = logger.getLogger('monappli.database') et puis log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug, info, warning,error, exception, critical...) Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs générés dans toute l'application. Ou bien se brancher uniquement sur 'monappli.database' pour ne voir que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les warning ou jusqu'au détail (debug). Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bien aller sur une application en production et passer en mode 'debug' pour voir ce qui se passe sans interrompre l'application. (Ils ont même prévu un socket serveur pour demander en live à l'appli de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut pluguer un handler qui va automatiquement faire des actions: - afficher à l'écran - écrire dans un fichier - écrire dans un fichier (avec log rotatif automatique) - envoyer à un syslog - écrire dans l'eventlog de Windows - envoyer sur un socket - envoyer une trame UDP - envoyer une requête HTTP - envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de filtres pour ne récupérer que les évènements qui vous intéressent. On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
Et comment on fait pour se "brancher" ?
utopia a écrit :
MyDomDom@gmail.com a écrit :
Bonjour,
J'en ai marre de faire des print... ;-)
-------------------------------------
source :
Comment ca marche . fr
http://www.commentcamarche.net/forum/affich-1245586-python-module-logging
------------------------------------
Quand vous avez une appli avec beaucoup de classes ou de threads, il
est parfois difficile de voir ce qui se passe.
Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre
application.
exemple:
monappli
monappli.database
monappli.database.updateUsers
monappli.mail
etc.
Ces logs sont accessible de n'importe où dans l'application.
Chacune de vos classes/threads peut loguer dans un de ces logs
(très simple:
log = logger.getLogger('monappli.database') et puis
log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug,
info, warning,error, exception, critical...)
Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour
écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs
générés dans toute l'application.
Ou bien se brancher uniquement sur 'monappli.database' pour ne voir
que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les
warning ou jusqu'au détail (debug).
Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bien
aller sur une application en production et passer en mode 'debug' pour
voir ce qui se passe sans interrompre l'application.
(Ils ont même prévu un socket serveur pour demander en live à l'appli
de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut
pluguer un handler qui va automatiquement faire des actions:
- afficher à l'écran
- écrire dans un fichier
- écrire dans un fichier (avec log rotatif automatique)
- envoyer à un syslog
- écrire dans l'eventlog de Windows
- envoyer sur un socket
- envoyer une trame UDP
- envoyer une requête HTTP
- envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de
filtres pour ne récupérer que les évènements qui vous intéressent.
On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
------------------------------------- source : Comment ca marche . fr http://www.commentcamarche.net/forum/affich-1245586-python-module-logging ------------------------------------ Quand vous avez une appli avec beaucoup de classes ou de threads, il est parfois difficile de voir ce qui se passe. Avec les threads, ça peut même tourner au cauchemard.
Le module logging permet d'avoir une hiérarchie de logs dans votre application.
exemple: monappli monappli.database monappli.database.updateUsers monappli.mail etc.
Ces logs sont accessible de n'importe où dans l'application. Chacune de vos classes/threads peut loguer dans un de ces logs (très simple: log = logger.getLogger('monappli.database') et puis log.info('coucou'), ou log.error('oups !')).
Il y a plusieurs niveaux de criticité pour chaque message (debug, info, warning,error, exception, critical...) Le module loggin enregistre tous ces messages.
Ensuite on peut se 'brancher' sur n'importe lequel de ces logs pour écouter les messages.
Par exemple, on peut se brancher sur 'monappli' pour voir les logs générés dans toute l'application. Ou bien se brancher uniquement sur 'monappli.database' pour ne voir que ce qui concerne la base de données.
On peut choisir le niveau de vue: ne voir que les criticals, les warning ou jusqu'au détail (debug). Et ça peut se changer dynamiquement: ça veut dire qu'on peut très bien aller sur une application en production et passer en mode 'debug' pour voir ce qui se passe sans interrompre l'application. (Ils ont même prévu un socket serveur pour demander en live à l'appli de changer sa configuration de log !)
C'est absolument génial pour débuguer un problème en prod !
Le plus fort, c'est que quand on se branche sur un log, on peut pluguer un handler qui va automatiquement faire des actions: - afficher à l'écran - écrire dans un fichier - écrire dans un fichier (avec log rotatif automatique) - envoyer à un syslog - écrire dans l'eventlog de Windows - envoyer sur un socket - envoyer une trame UDP - envoyer une requête HTTP - envoyer un mail (SMTP)
En plus des niveaux de criticité, ils ont même prévu un système de filtres pour ne récupérer que les évènements qui vous intéressent. On peut même définir ses propres niveaux de criticité.
Et évidemment ce module est totalement thread-safe.
