Discussion :

[robinechuca]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[MPython Alaplancha]

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 ...

[wiztricks]

Salut,

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

[tyrtamos]

Bonjour

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[robinechuca]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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!

[Sve@r]

Bonjour

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

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.

[robinechuca]

Merci, dans le vrai code j'ai mis

self._flux = flux

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

self.__flux = flux

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

[wiztricks]

Salut,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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()

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

[robinechuca]

bonjour,

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!

du coup voila ce que ça donne au final:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[wiztricks]

Salut,

du coup voila ce que ça donne au final:

Virez l'__init__!

- W

[Sve@r]

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 ???

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 python :

Sélectionner tout - Visualiser dans une fenêtre à part

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é...

[wiztricks]

Salut,

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

[robinechuca]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

f = deserialize(b"...")

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

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[wiztricks]

Salut,

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

[robinechuca]

Bonsoir,

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.