La clôture explicite des dossiers est-elle importante ?

Question

En Python, si vous ouvrez un fichier sans appeler close() ou fermer le fichier mais sans utiliser try - finally ou le " with "Cela pose-t-il un problème ? Ou est-il suffisant, en tant que pratique de codage, de s'appuyer sur le ramasse-miettes de Python pour fermer tous les fichiers ? Par exemple, si l'on fait ceci :

for line in open("filename"):
    # ... do stuff ...

... est-ce un problème parce que le fichier ne peut jamais être fermé et qu'une exception peut se produire qui l'empêche d'être fermé ? Ou bien le fichier sera-t-il définitivement fermé à la fin de l'opération for parce que le fichier sort du champ d'application ?

Answer 1

Dans votre exemple, la fermeture du fichier n'est pas garantie avant la sortie de l'interpréteur. Dans les versions actuelles de CPython, le fichier sera fermé à la fin de la boucle for, car CPython utilise le comptage de références comme principal mécanisme de ramassage des ordures, mais il s'agit d'un détail d'implémentation, et non d'une caractéristique du langage. D'autres implémentations de Python ne sont pas garanties de fonctionner de cette manière. Par exemple, IronPython, PyPy et Jython n'utilisent pas le comptage de références et ne fermeront donc pas le fichier à la fin de la boucle.

C'est une mauvaise pratique que de s'appuyer sur l'implémentation du garbage collection de CPython, car cela rend votre code moins portable. Il se peut que vous n'ayez pas de fuites de ressources si vous utilisez CPython, mais si vous passez à une implémentation de Python qui n'utilise pas le comptage de références, vous devrez revoir tout votre code et vous assurer que tous vos fichiers sont fermés correctement.

Pour votre exemple, utilisez :

with open("filename") as f:
     for line in f:
        # ... do stuff ...

Answer 2

Certains Python ferment automatiquement les fichiers lorsqu'ils ne sont plus référencés, tandis que d'autres ne le font pas et c'est au système d'exploitation de fermer les fichiers lorsque l'interpréteur Python quitte le système.

Même pour les Pythons qui ferment des fichiers pour vous, le moment n'est pas garanti : ce peut être immédiatement, ou quelques secondes/minutes/heures/jours plus tard.

Ainsi, même si vous ne rencontrez pas de problèmes avec le Python que vous utilisez, ce n'est certainement pas une bonne pratique que de laisser vos fichiers ouverts. En fait, dans cpython 3, vous recevrez désormais des avertissements indiquant que le système a dû fermer des fichiers pour vous si vous ne l'avez pas fait.

Moralité : nettoyez derrière vous :)

Answer 3

Bien qu'il soit tout à fait sûr d'utiliser une telle construction dans ce cas particulier, il y a quelques mises en garde à propos de la généralisation d'une telle pratique :

• run peut potentiellement être à court de descripteurs de fichiers, bien que cela soit peu probable, imaginez que vous soyez à la recherche d'un bogue de ce type.
• il se peut que vous ne puissiez pas supprimer ledit fichier sur certains systèmes, par exemple win32
• si vous utilisez autre chose que CPython, vous ne savez pas quand le fichier est fermé pour vous
• si vous ouvrez le fichier en mode écriture ou lecture-écriture, vous ne savez pas quand les données sont effacées

Answer 4

Le fichier est collecté et donc fermé. C'est le GC qui détermine quand il est fermé, pas vous. Il est évident que cette pratique n'est pas recommandée, car vous risquez d'atteindre la limite des gestionnaires de fichiers ouverts si vous ne fermez pas les fichiers dès que vous avez fini de les utiliser. Que se passe-t-il si, à l'intérieur de ce for de votre boucle, vous ouvrez plus de fichiers et les laissez traîner ?

Answer 5

Bonjour Il est très important de fermer votre descripteur de fichier dans le cas où vous allez utiliser son contenu dans le même script python. Je m'en suis rendu compte aujourd'hui après de longues heures de débogage. La raison est que le contenu ne sera édité/supprimé/enregistré qu'après avoir fermé le descripteur de fichier et que les modifications seront affectées au fichier !

Supposons donc que vous écriviez le contenu d'un nouveau fichier et que, sans fermer fd, vous utilisiez ce fichier (et non fd) dans une autre commande shell qui lit son contenu. Dans cette situation, vous n'obtiendrez pas le contenu de la commande shell comme prévu et si vous essayez de déboguer, vous ne pourrez pas trouver le bug facilement. vous pouvez également en savoir plus dans mon blog. http://magnificentzps.blogspot.in/2014/04/importance-of-closing-file-descriptor.html