l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
De plus, si le serveur est surchargé au niveau CPU, par un autre thread
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/
]
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a aucune signification en français... ;-)
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit! (Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite. C'est à n'y rien comprendre...
De plus, si le serveur est surchargé au niveau CPU, par un autre thread python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/ ]
l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a
aucune signification en français... ;-)
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et
l'objet fichier est automatiquement fermé, puis détruit!
(Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire
du code plus lisible et explicite.
C'est à n'y rien comprendre...
De plus, si le serveur est surchargé au niveau CPU, par un autre thread
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/
]
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a aucune signification en français... ;-)
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit! (Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite. C'est à n'y rien comprendre...
De plus, si le serveur est surchargé au niveau CPU, par un autre thread python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/ ]
Merci.
-- Amaury
R12y
Amaury Forgeot d'Arc :
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit!
Je me disais que ça pouvait se passer comme ça aussi...
(Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Non, pas encore de Jython chez moi :-)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite.
Disons que comme je fréquente beaucoup de programeur en C, ils me rabachent qu'il faut libérer le plus tot possible une ressource dont on ne se sert plus, mon premier reflexe a été de fd.close() le plus rapidement après de open(). Mais ça foirait le système...
C'est à n'y rien comprendre...
Mon code? Pas clair? je suis ouvert à des remarques plus verbeuses, si possible. J'ai codé ce truc à la va vite en plusieurs séances de 30 minutes... (entre deux cours...) Mais je vais le recoder, il y a une façon plus prepre de faire avec http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz. Le fichier example.py embarqué dans le tarball est... limpide.
Mais en quittant la fonction, la variable locale fd sort du scope, et
l'objet fichier est automatiquement fermé, puis détruit!
Je me disais que ça pouvait se passer comme ça aussi...
(Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Non, pas encore de Jython chez moi :-)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire
du code plus lisible et explicite.
Disons que comme je fréquente beaucoup de programeur en C, ils me
rabachent qu'il faut libérer le plus tot possible une ressource dont on ne
se sert plus, mon premier reflexe a été de fd.close() le plus rapidement
après de open(). Mais ça foirait le système...
C'est à n'y rien comprendre...
Mon code? Pas clair? je suis ouvert à des remarques plus verbeuses, si
possible. J'ai codé ce truc à la va vite en plusieurs séances de 30
minutes... (entre deux cours...)
Mais je vais le recoder, il y a une façon plus prepre de faire avec
http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz.
Le fichier example.py embarqué dans le tarball est... limpide.
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit!
Je me disais que ça pouvait se passer comme ça aussi...
(Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Non, pas encore de Jython chez moi :-)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite.
Disons que comme je fréquente beaucoup de programeur en C, ils me rabachent qu'il faut libérer le plus tot possible une ressource dont on ne se sert plus, mon premier reflexe a été de fd.close() le plus rapidement après de open(). Mais ça foirait le système...
C'est à n'y rien comprendre...
Mon code? Pas clair? je suis ouvert à des remarques plus verbeuses, si possible. J'ai codé ce truc à la va vite en plusieurs séances de 30 minutes... (entre deux cours...) Mais je vais le recoder, il y a une façon plus prepre de faire avec http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz. Le fichier example.py embarqué dans le tarball est... limpide.
Non non, c'est le problème que je ne vois pas. Il ne devrait pas y avoir de différence de comportement entre fd.close() ou pas !
-- Amaury
R12y
Amaury Forgeot d'Arc :
t.prout() J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a
aucune signification en français...
C'est pourtant la signification "en français" que je voulais donner à cette fonction. :-) De toutes façons, en fait, pour moi, anatomiquement, la sortie standard, ben c'est celle à laquelle on pense... J'ai tenté de mettre _un peu_ d'humour suggestif dans mon code.
t.prout()
J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a
aucune signification en français...
C'est pourtant la signification "en français" que je voulais donner à
cette fonction. :-)
De toutes façons, en fait, pour moi, anatomiquement, la sortie standard,
ben c'est celle à laquelle on pense...
J'ai tenté de mettre _un peu_ d'humour suggestif dans mon code.
t.prout() J'ai bien compris que 'prout' est tiré de l'anglais (print out), et n'a
aucune signification en français...
C'est pourtant la signification "en français" que je voulais donner à cette fonction. :-) De toutes façons, en fait, pour moi, anatomiquement, la sortie standard, ben c'est celle à laquelle on pense... J'ai tenté de mettre _un peu_ d'humour suggestif dans mon code.
J'ai tenté de mettre _un peu_ d'humour suggestif dans mon code.
s/sug/di/
jean-michel bain-cornu
Amaury Forgeot d'Arc wrote:
Bonjour,
J'ai un script python, qui fait un [...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) [...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit! (Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite. C'est à n'y rien comprendre...
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait
analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'. J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python. A+ jm
Amaury Forgeot d'Arc wrote:
Bonjour,
J'ai un script python, qui fait un
[...]
class Titre:
def __init__(self,p):
self.path=p
def prout(self):
fd=open(self.path,"rb")
sys.stdout.write(fd.read)
[...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque
quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et
l'objet fichier est automatiquement fermé, puis détruit!
(Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire
du code plus lisible et explicite.
C'est à n'y rien comprendre...
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait
analyser plusieurs milliers de fichier. Pour que ça marche bien, je
devais faire un 'del' explicite de l'objet fichier après le close, sinon
il se passait des trucs louches dans le genre de ce que tu décris.
Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
A+
jm
J'ai un script python, qui fait un [...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) [...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
Mais en quittant la fonction, la variable locale fd sort du scope, et l'objet fichier est automatiquement fermé, puis détruit! (Euh, sauf avec jython, mais ça ne semble pas être ton cas)
Ajouter fd.close() ne devrait pas changer grand chose... sauf à écrire du code plus lisible et explicite. C'est à n'y rien comprendre...
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait
analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'. J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python. A+ jm
F. Petitjean
Bonjour,
J'ai un script python, qui fait un
[...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) Il ne manquerait pas des patrnthèses après le .read ?
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1]) et si le fichier est une vidéo, il se peut qu'il soit volumineux et donc
un seul read() est une solution un poil expéditive (je ne sais pas de combien de mémoire est équipé votre serveur ni quelles sont les tailles des fichiers).
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . En lisant et en envoyant seulement des morceaux de taille raisonnable
cela devrait mettre un peu d'huile dans les rouages. (tester avec et sans sys.stdout.flush() après chaque sys.stdout.write(morceau) )
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose. De plus, si le serveur est surchargé au niveau CPU, par un autre thread python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/ ]
Merci.
Bonjour,
J'ai un script python, qui fait un
[...]
class Titre:
def __init__(self,p):
self.path=p
def prout(self):
fd=open(self.path,"rb")
sys.stdout.write(fd.read)
Il ne manquerait pas des patrnthèses après le .read ?
l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
et si le fichier est une vidéo, il se peut qu'il soit volumineux et donc
un seul read() est une solution un poil expéditive (je ne sais pas de
combien de mémoire est équipé votre serveur ni quelles sont les tailles
des fichiers).
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
En lisant et en envoyant seulement des morceaux de taille raisonnable
cela devrait mettre un peu d'huile dans les rouages. (tester avec et
sans sys.stdout.flush() après chaque sys.stdout.write(morceau) )
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
De plus, si le serveur est surchargé au niveau CPU, par un autre thread
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/
]
[...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) Il ne manquerait pas des patrnthèses après le .read ?
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1]) et si le fichier est une vidéo, il se peut qu'il soit volumineux et donc
un seul read() est une solution un poil expéditive (je ne sais pas de combien de mémoire est équipé votre serveur ni quelles sont les tailles des fichiers).
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . En lisant et en envoyant seulement des morceaux de taille raisonnable
cela devrait mettre un peu d'huile dans les rouages. (tester avec et sans sys.stdout.flush() après chaque sys.stdout.write(morceau) )
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose. De plus, si le serveur est surchargé au niveau CPU, par un autre thread python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/ ]
Merci.
R12y
F. Petitjean :
sys.stdout.write(fd.read) Il ne manquerait pas des patrnthèses après le .read ?
Si. Mais c'est parceque j'ai simplifié le bout de code, dans mon code il y a bien des (). Effectivement dans le "example.py" de shout-python, il envoie par tranche de 4096. Merci. --
sys.stdout.write(fd.read)
Il ne manquerait pas des patrnthèses après le .read ?
Si.
Mais c'est parceque j'ai simplifié le bout de code, dans mon code il y a
bien des ().
Effectivement dans le "example.py" de shout-python, il envoie par tranche
de 4096.
Merci.
--
sys.stdout.write(fd.read) Il ne manquerait pas des patrnthèses après le .read ?
Si. Mais c'est parceque j'ai simplifié le bout de code, dans mon code il y a bien des (). Effectivement dans le "example.py" de shout-python, il envoie par tranche de 4096. Merci. --
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les variables locales sont toutes détruites !
Enfin, en théorie... devant ce genre de problèmes, il faut rester humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait.
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait
analyser plusieurs milliers de fichier. Pour que ça marche bien, je
devais faire un 'del' explicite de l'objet fichier après le close, sinon
il se passait des trucs louches dans le genre de ce que tu décris.
Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les
variables locales sont toutes détruites !
Enfin, en théorie... devant ce genre de problèmes, il faut rester
humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait.
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les variables locales sont toutes détruites !
Enfin, en théorie... devant ce genre de problèmes, il faut rester humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait.
jean-michel bain-cornu
Amaury Forgeot d'Arc wrote:
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les variables locales sont toutes détruites ! +=1
Enfin, en théorie... devant ce genre de problèmes, il faut rester humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait. +=1
Amaury Forgeot d'Arc wrote:
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait
analyser plusieurs milliers de fichier. Pour que ça marche bien, je
devais faire un 'del' explicite de l'objet fichier après le close,
sinon il se passait des trucs louches dans le genre de ce que tu décris.
Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les
variables locales sont toutes détruites !
+=1
Enfin, en théorie... devant ce genre de problèmes, il faut rester
humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait.
+=1
ça me rappelle quelque chose. Un parser que j'avais fait et qui devait analyser plusieurs milliers de fichier. Pour que ça marche bien, je devais faire un 'del' explicite de l'objet fichier après le close, sinon il se passait des trucs louches dans le genre de ce que tu décris. Dans ton cas, j'essaierais 'del fd' après 'fd.close'.
...qui ne devrait rien changer non plus : en sortant de la fonction, les variables locales sont toutes détruites ! +=1
Enfin, en théorie... devant ce genre de problèmes, il faut rester humble, et accepter toute solution, même si elle ne semble pas logique.
J'ajoute que c'est le seul problème inexpliqué que j'aie eu avec python.
Si l'informatique était une science exacte, ça se saurait. +=1
