fermeture de fichier avec return

Bonjour, j'ai un souci avec un io.BufferedReader qui se ferme tout seul!
Je n'ai pas trouvé de solution sur le net, j'ose donc poster un nouveau sujet, j’espère.

Le code simplifié du problème:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

import io import os   def read(): class BufferedReader(io.BufferedReader): def __init__(self, *args, **kwargs): io.BufferedReader.__init__(self, *args, **kwargs) def __del__(self): os.remove(self.name)   with open("fichier", "wb") as f: f.write(b"voici le contenu du fichier...")   flux = open("fichier", mode="rb") f = BufferedReader(flux.raw)   print(f.read(5)) # affiche b'voici', donc c'est bon le fichier est ouvert return f   f = read() print(f.read(5)) # retourne ValueError: read of closed file

---

Je ne comprend pas pourquoi le fichier se ferme? Une idée de remède? :calim2:

Bonjour,
Je ne connais pas BufferedReader cependant je pense que ton souci est la ligne 21. Tu y modifies l'affectation de la variable f...
Qu'en est il?

édit:
désolé, je ne devais pas être bien réveillé ce matin ... :roll:

Salut,

Citation:

---

Envoyé par robinechuca

Je ne comprend pas pourquoi le fichier se ferme?

---

Déjà open(..., 'rb') retourne un io.BufferedReader (alors que 'r' retourne un TextIOWrapper), puis pourquoi faire BufferedReader(flux.raw) plutôt que f = BufferedReader(flux) ?

- W

Bonjour

Citation:

---

Envoyé par robinechuca

Je ne comprend pas pourquoi le fichier se ferme? Une idée de remède? :calim2:

---

Mon interprétation: à la fin de la fonction read, la variable locale "f" est bien retournée à la fin, mais l'autre variable locale "flux", crée à l'ouverture du fichier, disparait, ce qui empêche son utilisation ultérieure.

Solution: essaie de transmettre aussi "flux" au retour. Un petit code pour le montrer:

Code:

---

1 2 3 4 5 6 7

def test(): fs = open("monfichier.txt", "r", encoding="utf-8") return fs   f = test() for ligne in f: print(ligne)

---

Mais ça me parait un peu risqué: le fichier ouvert dans la fonction aurait pu être automatiquement fermé à la fin de la fonction (et je n'ai pas essayé avec BufferedReader).

Quand on fait un code complexe qui ne marche pas, il faut essayer de le décomposer pour tester les différents morceaux.

A vérifier aussi l'existence de la variable self.name dans la classe: elle n'est pas définie dans __init__, et je ne l'ai pas vue dans la doc des ancêtres.

Merci, effectivement, la solution consiste a laisser une trace de la variable locale 'flux'.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

import io import os     def read(): class BufferedReader(io.BufferedReader): def __init__(self, flux): io.BufferedReader.__init__(self, flux.raw) self.flux = flux # cette ligne ne sert pas a grand chose mis a part a duper le ramasse miette...   def __del__(self): os.remove(self.name)   # preparation du fichier with open("fichier_bis", "wb") as f: f.write(b"le contenu...")   # creation de l'objet flux = open("fichier_bis", mode="rb") # on tente de reproduire fidellement l'etat du flux serialise f = BufferedReader(flux)   print(f.read(5)) # la ca fonctionne car le 'flux' n'a pas ete extermine   return f   f = read() print(f.read(5))

---

Merci pour vos réponses, je pensais que conserver flux.raw suffisait a conserver 'flux', mais ce n'est pas le cas.
La variable self.name a toujours bien été définie dans toutes les situations que j'ai testées, mais dans le doute je vais l'encapsuler dans un try, except AttributeError .
Voila, problème résolu!

Bonjour

Citation:

---

Envoyé par robinechuca

self.flux = flux # cette ligne ne sert pas a grand chose mis a part a duper le ramasse miette...

---

Perso je mettrais self.__flux = flux pour rendre l'attribut non visible depuis l'extérieur. Ceci dit, contrairement à ton commentaire, c'est quand-même une ligne super importante. Elle permet justement de ne pas perdre ce paramètre "flux" reçu par le constructeur, ce qui est généralement le lot de tous les paramètres passés à un objet. Ben oui, quand on passe un truc à un objet, c'est généralement pour qu'il s'en serve donc qu'il le garde en interne ;)

Citation:

---

Envoyé par robinechuca

mais dans le doute je vais l'encapsuler dans un try, except AttributeError .

---

Là je ne suis pas d'accord car tu masquerais un défaut de conception. Si ton attribut "name" est bien un attribut licite et que tu es sûr de toi, alors tu n'as pas besoin de le surprotéger. Et si tu n'es pas sûr de toi, alors tu as le droit de surcharger toi-même la fonction open() pour t'assurer de toujours avoir le nom du fichier à ta portée pour pouvoir le supprimer à l'issue.
En fait, pour info, cet attribut fait partie de l'objet "BufferedReader" créé par open() donc (pour l'instant) il est licite. Et si demain (dans Python4 par exemple) il disparait, alors tu devras faire un portage de ton code pour que la destruction de l'objet continue à supprimer le fichier lu plutôt que ton code continue à tourner mais ne fasse plus le job.

Merci, dans le vrai code j'ai mis

Citation:

---

self._flux = flux

---

mais d'après la PEP 232, il faut bien metre

Citation:

---

self.__flux = flux

---

, j'ai confondu avec les fonctions cachée...

Salut,

Citation:

---

Envoyé par robinechuca

Merci, effectivement, la solution consiste a laisser une trace de la variable locale 'flux'.

---

En supprimant les problèmes que créé votre code, çà pourrait se résumer à:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

import io import os   def read(): class BufferedReader(io.BufferedReader): def close(self): super().close() os.remove(self.name)   # preparation du fichier with open("fichier_bis", "wb") as f: f.write(b"le contenu...")   # creation de l'objet flux = open("fichier_bis", mode="rb") # on tente de reproduire fidellement l'etat du flux serialise f = BufferedReader(flux)   print(f.read(5)) # la ca fonctionne car le 'flux' n'a pas ete extermine   return f   f = read() print(f.read(5)) ## f.close()

---

Citation:

---

Envoyé par robinechuca

Voila, problème résolu!

---

Si l'idée était de détruire le fichier lors du close, alors il y a encore du boulot car io.BufferedReader n'est pas le seul wrapper retourné par les différents mode d'open.

- W

bonjour,

Citation:

---

io.BufferedReader n'est pas le seul wrapper retourné par les différents mode d'open.

---

Oui bien-sur j'ai ici envoyé un code le plus simplifié possible pour mettre en avant le problème, dans le 'vrai' code, j'ai pris en compte:
-TextIOWrapper
-BufferedWriter
-BufferedReader
Cela s'inscrit dans une fonction de sérialisation, qui est capable de sérialiser des fichiers ouverts.

---

super(), c'est super, je n'avais pas osé redéfinir "def close(self)" de peur de perdre la méthode native, merci pour le tuyaux! :ccool:

du coup voila ce que ça donne au final:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class BufferedWriter(io.BufferedWriter): def __init__(self, flux, *args, **kwargs): io.BufferedWriter.__init__(self, flux.raw, *args, **kwargs) self.__flux = flux # permet de faire en sorte que le ramasse miette ne ferme pas le fichier   def close(self): super().close() self.__del__()   def __del__(self): try: os.remove(self.name) except AttributeError: pass

---

Salut,

Citation:

---

Envoyé par robinechuca

du coup voila ce que ça donne au final:

---

Virez l'__init__!

- W

Citation:

---

Envoyé par robinechuca

Oui bien-sur j'ai ici envoyé un code le plus simplifié possible pour mettre en avant le problème, dans le 'vrai' code, j'ai pris en compte:
-TextIOWrapper
-BufferedWriter
-BufferedReader
Cela s'inscrit dans une fonction de sérialisation, qui est capable de sérialiser des fichiers ouverts.

---

BufferedWriter ? Ca veut dire qu'après qu'une fois les opérations finies tu supprimes le fichier dans lequel tu viens d'écrire ??? :weird:

Ok, admettons. Mais pourquoi ne pas créer à la place un vrai context manager plutôt que passer par ce truc qui ressemble à un context manager, dont le nom sonne comme un context manager mais qui en réalité n'en est pas vraiment un ???

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

# Le context manager class myOpen: # Constructeur def __init__(self, name, *args, **kwargs): print("Création %s" % name)   # Il faut mémoriser les paramètres pour pouvoir les passer à open self.__name=name self.__args=args self.__kwargs=kwargs # __init__()   # Quand le context manager demande la ressource def __enter__(self): print("Ouverture %s" % self.__name)   # On ouvre le fichier (et on le mémorise pour la fermeture) self.__fp=open(self.__name, *self.__args, **self.__kwargs)   # Ici on retourne le fichier ouvert. Il sera accessible avec "as" return self.__fp # __enter__()   # Quand le context manager quitte le bloc def __exit__(self, tp, e, traceback): print( "Fermeture %s - tp=%s, e=%s, traceback=%s" % ( self.__name, tp, e, traceback, ) )   # On ferme le fichier, normal self.__fp.close()   # On efface le fichier puisqu'apparememnt c'est le but final de ce context manager import os os.remove(self.__name) # __exit__() # class myOpen   # Ecriture fichier d'exemple with open("toto", "w") as fp: fp.write("Hello World !!!")   # Vérification lecture standard with open("toto", "r") as fp: print("je lis1: ", fp.read())   # Test du context manager with myOpen("toto", "r") as fp: print("je lis2: ", fp.read())   # Normalement, ici il doit y avoir un FileNotFoundError puisque le fichier n'existe plus... with open("toto", "r") as fp: print("je lis3: ", fp.read())

---

Comme ça t'as plus besoin de te préoccuper de la nature du fichier (BufferedReader ? BufferedWriter ? etc) ni te préoccuper du devenir de l'attribut "name" avec ton try/except puisque le nom tu le gères de ton côté...

Salut,

Citation:

---

Envoyé par Sve@r

Mais pourquoi ne pas créer à la place un vrai context manager plutôt que passer par ce truc qui ressemble à un context manager, dont le nom sonne comme un context manager mais qui en réalité n'en est pas vraiment un ???

---

La question est de savoir pourquoi ne pas commencer par décrire le problème à résoudre plutôt que de partir à écrire du code avec des difficultés à le faire fonctionner.

D'aucuns auraient pu suggérer tempfile.NamedTemporaryFile qui fait déjà tout çà.

- W

Citation:

---

tu supprimes le fichier dans lequel tu viens d'écrire ???

---

Heu... Certe, je ne comprends pas comment j'ai pu ne pas m'en apercevoir :marteau:

Citation:

---

pourquoi ne pas créer à la place un vrai context manager

---

Ça pour le coup, c'est pas une erreur, c'est que ce code s'inscrit dans une fonction de dé-sérialisation qui se doit de retourner ce qui a été sérialisé. Si ce qui a été sérialisé est un fichier ouvert, alors cette fonction doit retourner un fichier ouvert.
de la façon suivante:

Code:

---

f = deserialize(b"...")

---

, cette syntaxe est imposée, sans 'with'.

Citation:

---

suggérer tempfile.NamedTemporaryFile qui fait déjà tout çà.

---

Je l'utilise déjà, en fait les fichiers sont créés dans un répertoire temporaire, généré par ce module.

Citation:

---

pourquoi ne pas commencer par décrire le problème à résoudre plutôt que de partir à écrire du code

---

Dans le but d’être clair et concis, j'ai simplifié au maximum le problème pour que d'autres aient plus de chance de pouvoir l'identifier, et aussi pour vous simplifier la tâche.
Mais j'ai peux-être un compromis à faire.

Donc le contexte c'est:
J'ai besoin d'une fonction de sérialisation / dé-sérialisation, un peu comme 'pickle' mais qui soit capable de sérialiser plus de choses, et surtout de sérialiser le contexte aussi, car la dé-sérialisation va se faire sur une autre machine.
J'aimerai que l'utilisateur puisse faire fonctionner le code suivant:

Code:

---

1 2 3 4 5 6 7 8

# sur une machine with open("petit_fichier", "r") as f: data = serialize(f) # retourne un type bytes   # sur une autre machine f = deserialize(data) # en fournissant le même 'data' print(f.read()) # par exemple, en tout cas, il faut que f ai le même comportement qu'a la ligne n°4

---

le code exhaustif se trouve là: https://framagit.org/robinechuca/rai...rialization.py

Mais en tout cas merci pour toutes vos réponses détaillées, vous me faite progresser.

Salut,

Citation:

---

Envoyé par robinechuca

ce code s'inscrit dans une fonction de dé-sérialisation qui se doit de retourner ce qui a été sérialisé. Si ce qui a été sérialisé est un fichier ouvert, alors cette fonction doit retourner un fichier ouvert.

---

désérialiser un fichier "ouvert", c'est avoir transférer les données du fichier et possiblement changer le chemin d'accès pour y accéder pour refaire le même open et un seek à la position courante pour continuer là où çà s'est arrêté.

Et si je fais f = open(path, ...), path se récupère dans f.name, le mode dans f.mode,... on peut fabriquer un dictionnaire capturant tout çà pour le rejouer "ailleurs". Et comme ce sera "open" qui choisira l'io wrapper en fonction du mode, je ne vois pas le soucis (ni le rapport avec la question originale).

- W

Bonsoir,

Citation:

---

désérialiser un fichier "ouvert", c'est avoir transférer les données du fichier et possiblement changer le chemin d'accès pour y accéder pour refaire le même open et un seek à la position courante pour continuer là où çà s'est arrêté.
on peut fabriquer un dictionnaire capturant tout çà pour le rejouer "ailleurs"

---

C'est exactement ce que j'ai fait (avec même d'autre champs encore comme 'encoding', 'errors'...) .
Juste pour éviter de laisser des traces sur le PC ou se passe la dé-sérialisation, (comme c'est pas directement l'utilisateur qui choisi), je met en place des fichiers qui s’ auto détruisent après leur utilisation.
Je dois reconnaître que ce contexte ne s'invente pas, j'aurais du être plus explicite.