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
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 :
Après :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 import random x = random.randint(0, 100) 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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 import random x = 21 print(x)
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.
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
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
Vérification en ligne de commande
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 import json from urllib import request print("salut")
erreur F401 mais un linter en détecte bien d'autres, 800 erreurs/avertissements ruff
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 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.
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)![]()
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.
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
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
Partager