Import des bibliotheques

Bonsoir, peut-on vérifier si les imports de bibliothèques en haut d'un script sont bien utilisées dans le corps du script.

pour les supprimer le cas échéant.

J'utilise VS Code

merci d'avance

Salut,

Si j'écris "import truc", les accès à la bibliothèque truc seront de la forme truc.xyz.
Par contre, en écrivant "from truc import xyz", lorsqu'on rencontre xyz, on ne saura pas comment a été initialisé cette variable globale.
Dans tous les cas, il faudrait pouvoir compter le nombre de références a truc lors de l'exécution pour savoir si le module est utilisé ou pas (c'est pas parce qu'une ligne utilise truc.xyz qu'on l'excute à chaque fois...)

- W

Bonsoir, exemple
Avant :

Code:

---

1 2 3 4

import random   x = random.randint(0, 100) print(x)

---

Après :

Code:

---

1 2 3 4

import random   x = 21 print(x)

---

Étant donné que j'ai supprimé la ligne random.randint et qu'il n'y a plus de ligne utilisant la bibliothèque random, il n'est pas inutile de laisser la ligne import random.

Donc, je voudrais savoir, s'il est possible de savoir, si une ligne d'import ne sert à rien pour se script.

Merci d'avance

Bonsoir,

un addon dans VsCode permet de griser les lignes d'import (et les variables) qui ne sont pas utilisées dans le script.

Voir du côté de pylance probablement.

Sinon, vous installez la librairie Python pylint que vous pouvez ensuite appeler en ligne de commande dans une console et qui vous dira si un import n'est pas utilisé.

Bonjour
pylint est un analyseur de code Python. Et entre autres il liste les import non utlisés.

Citation:

---

Envoyé par Yanss49

Donc, je voudrais savoir, s'il est possible de savoir, si une ligne d'import ne sert à rien pour se script.

---

C'est vous qui écrivez et modifiez le script... normalement vous devriez savoir.
Après, si vous voulez industrialiser la production du code(*), il y a des outils comme ceux déjà mentionnés.
(*) certifier de façon indépendante et automatisée de certaines qualités non technique d'un code.

- W

bonjour

oui, existe des outils avec cet éditeur (ligne surlignée automatiquement en rouge).

En autre, nous avons aussi ruff (dans vscode et autres éditeurs mais aussi en ligne de commande)

exemple de code

Code:

---

1 2 3 4

import json from urllib import request   print("salut")

---

Vérification en ligne de commande

Code:

---

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

ruff check truc.py truc.py:1:8: F401[*] `json` imported but unused | 1 | import json | ^^^^ F401 2 | from urllib import request | = help: Remove unused import: `json`   truc.py:2:20: F401[*] `urllib.request` imported but unused | 1 | import json 2 | from urllib import request | ^^^^^^^ F401 | = help: Remove unused import: `urllib.request`   Found 2 errors.[*] 2 fixable with the `--fix` option.

---

erreur F401 mais un linter en détecte bien d'autres, 800 erreurs/avertissements ruff

sinon une façon empirique: tu commentes l'import et tu regardes si tu as une erreur, si oui, c'est que l'import est utilisé (il faut testé toutes fonctionnalités pour en être sûr) :mrgreen:

Merci pour vos réponses

Citation:

---

Envoyé par wiztricks

C'est vous qui écrivez et modifiez le script... normalement vous devriez savoir.

---

Ca c'est la théorie.
Dans la réalité, on importe une lib puis on l'utilise une fois, deux fois, trois fois. Puis le code évolue et on efface la première occurrence. Puis le code évolue encore et on efface la seconde occurrence. Puis le code évolue et on rajoute une 4°. Puis on efface la 3°. Puis etc etc. Et au final on ne sait plus trop où on en est.

Citation:

---

Envoyé par Sve@r

Puis le code évolue et on rajoute une 4°. Puis on efface la 3°. Puis etc etc. Et au final on ne sait plus trop où on en est.

---

Si c'est le cas, on repart de zéro en espérant d'arriver à maîtriser un peu mieux le bousin.
Quand je codais professionnellement, les revues de code étaient faites par des humains qui posaient des tas de questions sur le design, les algos, ... passer les tests "automatisables" était juste un prérequis à une revue.

- W

Citation:

---

Envoyé par wiztricks

Si c'est le cas, on repart de zéro en espérant d'arriver à maîtriser un peu mieux le bousin.

---

Oui mais les choses évoluent aussi de façon indépendante mais qui vont avoir un impact. Par exemple j'utilisais os.path pour créer des chemins. Puis un jour est apparu pathlib. De là, j'ai repris mes codes évidemment, je ne suis pas reparti de zéro. Ce n'est pas une histoire de maîtrise ça. Après oui j'ai checké si import os se justifiait encore mais tout n'est pas toujours simple et ce n'est pas qu'une question de "espérer arriver à maîtriser le bousin".

Citation:

---

Envoyé par Sve@r

Puis un jour est apparu pathlib. De là, j'ai repris mes codes évidemment, je ne suis pas reparti de zéro.

---

Je ne sais pas... je dirais "quelle idée?!?"
os.path est toujours là et le remplacer par pathlib dans des codes qui marchent juste parce que c'est "moderne" n'a pas grand intérêt (sauf de se dire que c'est un exercice "utile"). On fait plutôt ça pour de nouveaux codes ou éventuellement à l'occasion de gros chantiers qui ajoutent/modifient des fonctionnalités conduisant à revoir/ré-écrire pas mal de code.

Citation:

---

Envoyé par Sve@r

Après oui j'ai checké si import os se justifiait encore mais tout n'est pas toujours aussi simple.

---

Avec les vieux codes, le plus difficile, est de rester concentré sur les changements à effectuer plutôt que de reprendre tout ce qui ne nous plait pas. Après remplacer l'utilisation de la bibliothèque machin par la bibliothèque truc se fait plus ou moins facilement... car ça peut être la réécriture de quelques lignes a un petit projet où il va peut être falloir expliciter les cas d'utilisation de machin dans une façade (au sens OO) qui réalise l'interface. Eventuellement booster les codes de tests pour s'assurer que le fonctionnel est équivalent (ainsi que les performances) puis...

- W

Perso, avec toujours un linteur, je me pose plus que rarement ce type de question ;)

request <--> urllib, os.path <--> pathlib, tucpdf <---> pdfmachin
En refactoring : je ne risque pas d'avoir ce type de problème puisque je vais créer une granche git spécifique au besoin et le commit sera forcément sans cette "ancienne" lib

Mais, parfois, sans linteur, cela peut devenir un petit casse tête avec de gros framework/libs (Qt, ...)

Code:

---

1 2	from lib.exceptions import erreursNet, erreursRéseau, erreurs??? from lib.constantes import couleurs, events, ???, ???

---

Citation:

---

Envoyé par papajoker

Mais, parfois, sans linteur, cela peut devenir un petit casse tête avec de gros framework/libs (Qt, ...)

Code:

---

1 2	from lib.exceptions import erreursNet, erreursRéseau, erreurs??? from lib.constantes import couleurs, events, ???, ???

---

---

Sûr qu'écrire erreursNet au lieu de lib.exceptions.erreursNet est moins fatiguant!
Je n'utilise cette définition de variables globales que pour de petits exemples/brouillons.

Dans la pratique, je préfère définir un alias via import lib.exceptions as libe et assigner erreursNet = libe.erreursNet avant l'entrée dans une boucle pour utiliser erreursNet et optimiser (çà évite l'indirection).

Ceci dit ma pratique professionnelle s'est arrêtée il y a une dizaine d'année déjà. A l'époque, un pylint était encore un prototype en version 0.x. Depuis tout cela a bien murit et le typing a ajouté une couche qui permet une certaine industrialisation qui rendent un peu obsolètes ce qui pouvait s'appeler "bonnes pratiques".

- W