J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois),
où il provoque cette erreur :
File "C:\serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne
comprends pas pourquoi un simple print peut provoquer une erreur (en
plus, moins d'une fois sur mille).
Précisions :
Windows-2003-server, qui sert essentiellement en tant que serveur de
fichiers
Python 2.5.1
Même en cas d'erreur les lancements suivants du script fonctionnent
bien (la tache planifiée lance un nouveau processus à chaque fois).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Desthuilliers
Bonjour !
J'ai un script, qui tourne sur un serveur, tous les 1/4 h. Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois), où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales* d'un programme. Les erreurs, traces et autres devraient aller sur sys.stderr.
(en plus, moins d'une fois sur mille).
Précisions : Windows-2003-server, qui sert essentiellement en tant que serveur de fichiers Python 2.5.1 Même en cas d'erreur les lancements suivants du script fonctionnent bien (la tache planifiée lance un nouveau processus à chaque fois).
Une idée ?
Est-ce que par hasard la stdout du système serait redirigée vers un fichier de log lors de l'appel du script ? Si oui, le pb doit être par là.
Sinon, attrape l'exception et logue (dans un fichier) un rapport sur l'état de sys.stdout.
Désolé, pas mieux.
Bonjour !
J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois),
où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne
comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le
flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si
ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales*
d'un programme. Les erreurs, traces et autres devraient aller sur
sys.stderr.
(en
plus, moins d'une fois sur mille).
Précisions :
Windows-2003-server, qui sert essentiellement en tant que serveur de
fichiers
Python 2.5.1
Même en cas d'erreur les lancements suivants du script fonctionnent
bien (la tache planifiée lance un nouveau processus à chaque fois).
Une idée ?
Est-ce que par hasard la stdout du système serait redirigée vers un
fichier de log lors de l'appel du script ? Si oui, le pb doit être par là.
Sinon, attrape l'exception et logue (dans un fichier) un rapport sur
l'état de sys.stdout.
J'ai un script, qui tourne sur un serveur, tous les 1/4 h. Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois), où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales* d'un programme. Les erreurs, traces et autres devraient aller sur sys.stderr.
(en plus, moins d'une fois sur mille).
Précisions : Windows-2003-server, qui sert essentiellement en tant que serveur de fichiers Python 2.5.1 Même en cas d'erreur les lancements suivants du script fonctionnent bien (la tache planifiée lance un nouveau processus à chaque fois).
Une idée ?
Est-ce que par hasard la stdout du système serait redirigée vers un fichier de log lors de l'appel du script ? Si oui, le pb doit être par là.
Sinon, attrape l'exception et logue (dans un fichier) un rapport sur l'état de sys.stdout.
Désolé, pas mieux.
Amaury Forgeot d'Arc
Bonjour !
J'ai un script, qui tourne sur un serveur, tous les 1/4 h. Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois), où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales* d'un programme. Les erreurs, traces et autres devraient aller sur sys.stderr.
Attention sous Windows, si tu utilises pythonw.exe ou des scripts en .pyw:
pythonw.exe n'est pas une application console, ses sys.sdtout et sys.stderr ne sont connectés à rien.
Les premiers "print" se passent bien (même si on ne les voit pas). Mais au bout de 1024 caractères, il doit y avoir un flush() interne, et boum.
-- Amaury
Bonjour !
J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par
mois), où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je
ne comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le
flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si
ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales*
d'un programme. Les erreurs, traces et autres devraient aller sur
sys.stderr.
Attention sous Windows, si tu utilises pythonw.exe ou des scripts en .pyw:
pythonw.exe n'est pas une application console, ses sys.sdtout et
sys.stderr ne sont connectés à rien.
Les premiers "print" se passent bien (même si on ne les voit pas).
Mais au bout de 1024 caractères, il doit y avoir un flush() interne, et
boum.
J'ai un script, qui tourne sur un serveur, tous les 1/4 h. Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois), où il provoque cette erreur :
File "C:serv.py", line 69, in TCPersistEnvoiTxt print "va envoyer"
IOerror: [Errno 9] Bad file descriptor
A chaque fois, le script étant relancé de zéro (tache planifiée), je ne comprends pas pourquoi un simple print peut provoquer une erreur
print écrit sur le flux de sortie standard (ou, plus exactement, sur le flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si ce file descriptor est en vrac pour une raison ou une autre...
Accessoirement, sys.stdout est destiné à recevoir les sorties *normales* d'un programme. Les erreurs, traces et autres devraient aller sur sys.stderr.
Attention sous Windows, si tu utilises pythonw.exe ou des scripts en .pyw:
pythonw.exe n'est pas une application console, ses sys.sdtout et sys.stderr ne sont connectés à rien.
Les premiers "print" se passent bien (même si on ne les voit pas). Mais au bout de 1024 caractères, il doit y avoir un flush() interne, et boum.
-- Amaury
Méta-MCI \(MVP\)
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (en pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serveur). Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux...
@+
Michel Claveau
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (en
pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un
serveur).
Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux...
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (en pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serveur). Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux...
@+
Michel Claveau
bruno.desthuilliers
On 24 avr, 20:51, "Méta-MCI (MVP)" wrote:
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (en pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serveur). Je vais diminuer les "print", pour voir.
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
On 24 avr, 20:51, "Méta-MCI (MVP)" <enleverlesX.X...@XmclaveauX.com>
wrote:
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (en
pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un
serveur).
Je vais diminuer les "print", pour voir.
Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (en pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serveur). Je vais diminuer les "print", pour voir.
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
MC
'soir !
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes système similaire à la sortie standard.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Merci de m'avoir lu, et pour les suggestions.
-- @-salutations
Michel Claveau
'soir !
Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes
système similaire à la sortie standard.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet
d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes système similaire à la sortie standard.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Merci de m'avoir lu, et pour les suggestions.
-- @-salutations
Michel Claveau
Bruno Desthuilliers
'soir !
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes système similaire à la sortie standard.
???
Tu veux dire "à condition que ce flux", je suppose (sinon ça n'a aucun sens puisque sys.stdout *est* la sortie standard). Et je ne vois pas de raisons pour qu'un fichier soit soumis à ce genre de contraintes.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
'soir !
Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes système
similaire à la sortie standard.
???
Tu veux dire "à condition que ce flux", je suppose (sinon ça n'a aucun
sens puisque sys.stdout *est* la sortie standard). Et je ne vois pas de
raisons pour qu'un fichier soit soumis à ce genre de contraintes.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet
d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Et si tu utilisais le module de log au lieu de la sortie standard, tout
simplement ?
Une autre solution est de rediriger stdout sur un autre flux ouvert en écriture (un fichier par exemple). Il suffit d'assigner ce flux à sys.stdout, donc pas besoin d'aller toucher au reste du code.
Oui, à condition que sys.stdout ne tombe pas sur des contraintes système similaire à la sortie standard.
???
Tu veux dire "à condition que ce flux", je suppose (sinon ça n'a aucun sens puisque sys.stdout *est* la sortie standard). Et je ne vois pas de raisons pour qu'un fichier soit soumis à ce genre de contraintes.
Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
Méta-MCI \(MVP\)
Re !
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts tournent sur plusieurs sites, dont certains pour lesquels print est beaucoup plus facile à utiliser (serveurs sans clavier, par exemple). Et, ça m'embêterait d'avoir plusieurs versions.
D'autant plus que ça contournerait le problème, sans expliquer son origine ; alors que, en réduisant simplement le print, c'est comme un outil de diagnostic.
Il faut quand même que je rappelle que, lorsqu'il y a l'erreur, cela ne bloque pas le script (l'erreur est interceptée), et, même avec un script bloqué, les suivants fonctionnent (car ils sont lancés par des taches planifiées).
@+
MCI
Re !
Et si tu utilisais le module de log au lieu de la sortie standard,
tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts
tournent sur plusieurs sites, dont certains pour lesquels print est
beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).
Et, ça m'embêterait d'avoir plusieurs versions.
D'autant plus que ça contournerait le problème, sans expliquer son
origine ; alors que, en réduisant simplement le print, c'est comme un
outil de diagnostic.
Il faut quand même que je rappelle que, lorsqu'il y a l'erreur, cela ne
bloque pas le script (l'erreur est interceptée), et, même avec un script
bloqué, les suivants fonctionnent (car ils sont lancés par des taches
planifiées).
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts tournent sur plusieurs sites, dont certains pour lesquels print est beaucoup plus facile à utiliser (serveurs sans clavier, par exemple). Et, ça m'embêterait d'avoir plusieurs versions.
D'autant plus que ça contournerait le problème, sans expliquer son origine ; alors que, en réduisant simplement le print, c'est comme un outil de diagnostic.
Il faut quand même que je rappelle que, lorsqu'il y a l'erreur, cela ne bloque pas le script (l'erreur est interceptée), et, même avec un script bloqué, les suivants fonctionnent (car ils sont lancés par des taches planifiées).
@+
MCI
Boris Borcic
Méta-MCI (MVP) wrote:
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (e n pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serve ur). Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux ...
@+
Michel Claveau
Peut-être les modules win32trace / win32traceutil pourraient-ils là s ervir (qui viennent avec les "windows python extensions" de Mark Hammond). Voilà l e commentaire au début de win32traceutil.py (intégré à Pythonwin). HTH. BB
# This is a helper for the win32trace module
# If imported from a normal Python program, it sets up sys.stdout and sys .stderr # so output goes to the collector.
# If run from the command line, it creates a collector loop.
# Eg: # C:>start win32traceutil.py (or python.exe win32traceutil.py) # will start a process with a (pretty much) blank screen. # # then, switch to a DOS prompt, and type: # C:>python.exe # Python 1.4 etc... # >>> import win32traceutil # Redirecting output to win32trace remote collector # >>> print "Hello" # >>> # And the output will appear in the first collector process.
# Note - the client or the collector can be started first. # There is a 64k buffer. If this gets full, it is reset, and new # output appended from the start.
Méta-MCI (MVP) wrote:
Bonsoir !
L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (e n
pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un serve ur).
Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux ...
@+
Michel Claveau
Peut-être les modules win32trace / win32traceutil pourraient-ils là s ervir (qui
viennent avec les "windows python extensions" de Mark Hammond). Voilà l e
commentaire au début de win32traceutil.py (intégré à Pythonwin). HTH. BB
# This is a helper for the win32trace module
# If imported from a normal Python program, it sets up sys.stdout and sys .stderr
# so output goes to the collector.
# If run from the command line, it creates a collector loop.
# Eg:
# C:>start win32traceutil.py (or python.exe win32traceutil.py)
# will start a process with a (pretty much) blank screen.
#
# then, switch to a DOS prompt, and type:
# C:>python.exe
# Python 1.4 etc...
# >>> import win32traceutil
# Redirecting output to win32trace remote collector
# >>> print "Hello"
# >>>
# And the output will appear in the first collector process.
# Note - the client or the collector can be started first.
# There is a 64k buffer. If this gets full, it is reset, and new
# output appended from the start.
L'hypothèse du buffer plein est une piste intéressante. Car, en fait, le script s'exécute dans une console qui n'est pas la console d'administration, et n'est donc pas affichée par défaut (e n pratique, je me connecte à distance en RDP).
Mais, si c'est ça, la taille avant que le buffer ne soit plein est beaucoup plus grande que 1024 caractères (et puis, c'est sur un serve ur). Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux ...
@+
Michel Claveau
Peut-être les modules win32trace / win32traceutil pourraient-ils là s ervir (qui viennent avec les "windows python extensions" de Mark Hammond). Voilà l e commentaire au début de win32traceutil.py (intégré à Pythonwin). HTH. BB
# This is a helper for the win32trace module
# If imported from a normal Python program, it sets up sys.stdout and sys .stderr # so output goes to the collector.
# If run from the command line, it creates a collector loop.
# Eg: # C:>start win32traceutil.py (or python.exe win32traceutil.py) # will start a process with a (pretty much) blank screen. # # then, switch to a DOS prompt, and type: # C:>python.exe # Python 1.4 etc... # >>> import win32traceutil # Redirecting output to win32trace remote collector # >>> print "Hello" # >>> # And the output will appear in the first collector process.
# Note - the client or the collector can be started first. # There is a 64k buffer. If this gets full, it is reset, and new # output appended from the start.
Bruno Desthuilliers
Re !
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts tournent sur plusieurs sites, dont certains pour lesquels print est beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).
Qu'est-ce que ça change ???
Et, ça m'embêterait d'avoir plusieurs versions.
Le module logger peut envoyer ses infos sur sys.st[dout|err].
D'autant plus que ça contournerait le problème,
Non. Encore une fois, print affiche sur sys.sdtout, qui est destiné à recevoir les sorties *normales* d'un programme. les messages d'erreurs et autres, ça va sur sys.stderr. Et le module logger sert très précisément à gérer les traces et autres infos de fonctionnement avec plus de détails qu'une écriture directe sur sys.stderr.
sans expliquer son origine ;
Ca c'est un autre problème.
Re !
Et si tu utilisais le module de log au lieu de la sortie standard,
tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts
tournent sur plusieurs sites, dont certains pour lesquels print est
beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).
Qu'est-ce que ça change ???
Et, ça m'embêterait d'avoir plusieurs versions.
Le module logger peut envoyer ses infos sur sys.st[dout|err].
D'autant plus que ça contournerait le problème,
Non. Encore une fois, print affiche sur sys.sdtout, qui est destiné à
recevoir les sorties *normales* d'un programme. les messages d'erreurs
et autres, ça va sur sys.stderr. Et le module logger sert très
précisément à gérer les traces et autres infos de fonctionnement avec
plus de détails qu'une écriture directe sur sys.stderr.
Et si tu utilisais le module de log au lieu de la sortie standard, tout simplement ?
Alors, log, ça irait pour cette installation ; mais les mêmes scripts tournent sur plusieurs sites, dont certains pour lesquels print est beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).
Qu'est-ce que ça change ???
Et, ça m'embêterait d'avoir plusieurs versions.
Le module logger peut envoyer ses infos sur sys.st[dout|err].
D'autant plus que ça contournerait le problème,
Non. Encore une fois, print affiche sur sys.sdtout, qui est destiné à recevoir les sorties *normales* d'un programme. les messages d'erreurs et autres, ça va sur sys.stderr. Et le module logger sert très précisément à gérer les traces et autres infos de fonctionnement avec plus de détails qu'une écriture directe sur sys.stderr.
