Salut,
Pas mal ce retravail de ton tutoriel, je trouve que c’est beaucoup mieux cadré !
Mémoires et fichiers
Au niveau de la mémoire en parlant des différents types, est-ce que tu penses aussi parler de mémoire cache ?
Ensuite je ne sais pas si « disque dur » est le terme le plus adapté aujourd’hui pour parler de la mémoire persistante avec les SSD un peu partout.
Je ne suis pas sûr qu’il soit intéressant de voir la mémoire comme un tableau de bits plutôt qu’un tableau d’octets. Y a-t-il vraiment des mémoires utilisées aujourd’hui que l’on peut manipuler aussi finement ?
Je dirais que les abstractions qui permettent de visualiser la mémoire comme des cases (parce que ce n’est alors plus une considération physique) le font plutôt avec des tableaux d’octets.
J’ai du mal à comprendre la transition que tu fais entre les octets et les fichiers et je trouve bizarre de parler d’un répertoire qui couvrirait l’intégralité du disque dur, ça ne me semble pas correspondre à la réalité des systèmes de fichiers.
Tu n’en parles d’ailleurs pas du tout, pourtant ceux sont eux qui permettent de faire la liaison entre fichiers comme ensembles d’octets et octets stockés sur un disque.
En lisant tes explications on pourrait croire que les répertoires sont des espèces de partitions du disque. Pourtant du point de vue du disque les répertoires n’existent même pas. C’est le système de fichiers qui stocke des blocs de données particuliers sur le disque pour donner forme à une telle hiérarchie totalement abstraite.
À la suite de ton croquis représentant l’arborescence du système tu parles d’éléments en rouge représentant l’adresse d’un fichier particulier. Je n’ai pas vu de rogue sur le croquis.
Tu dis qu’un chemin relatif ne permet pas d’accéder à tous les fichiers, j’aimerais bien plus de précisions là-dessus, pourquoi ne pourrait-on pas remonter jusqu’à un répertoire parent avec .. pour ensuite redescendre où l’on veut ?
Ça fait aussi justement qu’un chemin relatif peut être plus long qu’un absolu : si je veux pointer le fichier /etc/fstab depuis mon répertoire /home/entwanne je dois utiliser pour chemin relatif ../../etc/fstab.
Le module pathlib
Je trouve que ça manque un peu d’exemples d’utilisation, et notamment de ce qui est vraiment utilise dans ce module : la formation de chemins avec l’opérateurs /, les méthodes utiles pour manipuler des chemins concrets (open, read_text, etc.).
Difficile en l’état de comprendre le but de ce chapitre.
Le module os
Pour résoudre le problème évoqué dans la première section je pense qu’il serait plus judicieux de recevoir un chemin en argument du programme et de l’utiliser comme base pour les opérations qui suivent plutôt que de changer de répertoire courant.
Le changement de répertoire pourrait avoir des effets indésirables (notamment sur l’import de modules Python).
Tu dis que la fonction os.rmdir supprime un répertoire et son contenu, pourtant il me semble qu’elle lève une exception quand le répertoire n’est pas vide.
À propos de os.rename tu devrais parler des limitations de la fonction (impossible de déplacer un fichier vers une autre partition) et peut-être introduire le module shutil.
Les opérations que tu présentes sur les chemins dans ce chapitre mériteraient d’être aussi étudiées dans le chapitre concernant pathlib.
Les fichiers textuels
Dans la première section tu dis que les fichier texte sont encodés en UTF-8 (ce n’est pas toujours le cas) et que chaque caractère est encodé sur un octet (ce n’est souvent pas le cas), tu devrais vérifier tes informations.
Pour ce qui est du \n il correspond bien à un seul caractère (l’entrée 0x0A dans la table ASCII) codé sur un octet dans les encodages basés sur ASCII. \n n’est qu’une représentation de ce caractère.
Dans la deuxième section je ne comprends pas ta phrase « il faut absolument le fermer, sinon on ne pourra plus accéder au fichier via Python ».
Pourquoi as-tu deux foisfile.close() dans ton exemple sur le try/finally ?
Le bloc finally est exécuté dans tous les cas, qu’une exception soit levée ou non, il n’est donc pas nécessaire de fermer le fichier dans le bloc try puisqu’il sle sera dans le finally.
De même, pourquoi mets-tu un file.close() dans le bloc with alors que c’est justement l’intérêt de ce bloc que de ferme le fichier par lui-même ?
Sur quoi te bases-tu pour dire qu’il « este préférable de terminer le bloc par l’instruction file.close() » ?
Dans la troisième section tu dis qu’un fichier ne pourrait pas être ouvert à la fois en lecture et écriture, c’est pourtant permis par exemple par le mode r+ et d’autres.
Tu oublies aussi de préciser que le mode w tronque le contenu du fichier, tu expliques même l’inverse dans la section « Écrire dans un fichier » où tu présentes un exemple où le contenu ne serait pas tronqué.
Le mode x permet parfaitement d’écrire dans un fichier, il assure juste que le fichier n’existait pas avant.
Les fichiers ne possèdent pas de méthode trunc mais une méthode truncate, as-tu essayé les exemples que tu présentes ?
Ton exemple de fichier JSON est invalide, il manque des virgules par endroits.
Pour ce qui est des modules csv et json je pense que tu devrais plutôt donner en lien les pages de doc de ces modules qu’un site bourré de publicités.
Pourquoi parler de pickle dans un chapitre sur les fichiers texte ? Et pourquoi dis-tu que le module nécessite d’être installé via pip (il fait partie de la bibliothèque standard) ?
Les exemples que tu utilises ensuite ne sont pas bon puisque pickle attend des fichiers et non des chemins.
Le module pandas
Je reste sur ma faim après ce chapitre, au final tu ne présentes pandas que pour lire/écrire des fichiers dans différents formats et bénéficier d’une méthode filter un peu magique.
N’y a-t-il pas d’autres choses utiles dans ce paquet qui mériteraient d’être détaillées ici ?
