Comment désactiver un avertissement Pylint?
J'essaie de désactiver l'avertissement C0321 ("Plusieurs instructions sur une seule ligne" - je mets souvent des instructions if avec des résultats courts sur une seule ligne), dans Pylint 0.21.1 (si questions: astng 0.20.1, commun 0.50.3, Python 2.6.6 (r266: 84292, 15 sept 2010, 16:22:56)).
J'ai essayé d'ajouter disable=C0321 dans le fichier de configuration de Pylint, mais Pylint insiste néanmoins pour le signaler. Les variations sur cette ligne (comme disable=0321 ou disable=C321) sont signalées comme des erreurs, donc Pylint reconnaît correctement l'option, c'est juste l'ignorer.
Est-ce un bug de Pylint ou est-ce que je fais quelque chose de mal? Y a-t-il un moyen de contourner cela? J'aimerais vraiment me débarrasser de ce bruit.
pylint --generate-rcfile le montre comme ceci:
[MESSAGES CONTROL]
# Enable the message, report, category or checker with the given id(s). You can
# either give multiple identifier separated by comma (,) or put this option
# multiple time.
#enable=
# Disable the message, report, category or checker with the given id(s). You
# can either give multiple identifier separated by comma (,) or put this option
# multiple time (only on the command line, not in the configuration file where
# it should appear only once).
#disable=
Donc, il semble que votre ~/.pylintrc devrait avoir le disable= ligne/s à l'intérieur d'une section [MESSAGES CONTROL].
J'ai eu ce problème en utilisant Éclipse et résolu comme suit:
dans le dossier pylint (par exemple, C:\Python26\Lib\site-packages\pylint), maintenez la touche Maj enfoncée, cliquez avec le bouton droit de la souris et choisissez d’ouvrir la commande windows de ce dossier. Type:
lint.py --generate-rcfile > standard.rc
Cela crée le fichier de configuration standard.rc. Ouvrez-le dans le bloc-notes et sous [MESSAGES CONTROL], annulez le commentaire disable= et ajoutez les ID de message que vous souhaitez désactiver, par exemple:
disable=W0511, C0321
Enregistrez le fichier et dans Eclipse-> window-> préférences-> PyDev-> pylint, dans la zone des arguments, tapez:
--rcfile=C:\Python26\Lib\site-packages\pylint\standard.rc
Maintenant ça devrait marcher ...
Vous pouvez aussi ajouter un commentaire en haut de votre code qui sera interprété par pylint:
# pylint: disable=C0321
lien vers tous codes de message pylint
Ajouter par exemple --disable-ids=C0321 dans la boîte à arguments ne fonctionne pas. Tous les messages pylint disponibles sont stockés dans le dictionnaire _messages, attribut d'une instance de la classe pylint.utils.MessagesHandlerMixIn. Lors de l'exécution de pylint avec l'argument --disable-ids=... (au moins sans fichier de configuration), ce dictionnaire est initialement vide et déclenche une exception KeyError dans pylint (pylint.utils.MessagesHandlerMixIn.check_message_id(). Dans Eclipse, vous pouvez voir ce message d'erreur dans la console Pylint (windows - show view - Console, sélectionnez Pylint Console dans les options de la console, à côté de l’icône de la console.)
À partir de Pylint v. 0.25.3, vous pouvez utiliser les noms symboliques pour désactiver les avertissements au lieu de devoir mémoriser tous ces numéros de code . Par exemple.:
# pylint: disable=locally-disabled, multiple-statements, fixme, line-too-long
Ce style est plus instructif que les codes d'erreur cryptiques et également plus pratique, car les versions les plus récentes de Pylint ne fournissent que le nom symbolique, pas le code d'erreur.
La correspondance entre les noms symboliques et les codes peut être trouvée ici .
Un commentaire de désactivation peut être inséré sur sa propre ligne, en appliquant la désactivation à tout ce qui suit dans le même bloc. Alternativement, il peut être inséré à la fin de la ligne pour laquelle il est censé s'appliquer.
Si pylint génère les messages "Locally disabling", vous pouvez les supprimer en incluant le paramètre disable locally-disabled en premier , comme dans l'exemple. au dessus de.
Pour désactiver un avertissement localement dans un bloc, ajoutez
# pylint: disable=C0321
à ce bloc.
Il existe plusieurs façons de désactiver les avertissements et les erreurs de Pylint. Laquelle utiliser dépend de la manière dont vous voulez appliquer l’invalidité au niveau mondial ou local - une décision de conception importante.
Approches multiples
- Dans un ou plusieurs fichiers
pylintrc.
Cela implique plus que le fichier ~/.pylintrc (dans votre répertoire $ HOME) tel que décrit par Chris Morgan. Pylint recherchera les fichiers rc, avec une priorité qui valorisera davantage les fichiers "plus proches":
Un fichier
pylintrcdans le répertoire de travail actuel; ouSi le répertoire de travail actuel est dans un module Python (c'est-à-dire qu'il contient un fichier
__init__.py), recherchez la hiérarchie des modules Python jusqu'à un fichierpylintrcest trouvé; ouLe fichier nommé par la variable d'environnement PYLINTRC; ou
Si vous avez un répertoire personnel qui n’est pas
/root:~/.pylintrc; ou~/.config/pylintrc; ou/etc/pylintrc
Notez que la plupart de ces fichiers sont nommés pylintrc - seul le fichier dans ~ a un point en tête.
Dans votre fichier pylintrc, ajoutez des lignes pour désactiver des messages pylint spécifiques. Par exemple:
[MESSAGES CONTROL]
disable=locally-disabled
Désactivez ensuite la ligne de commande
pylint, comme décrit par Aboo et Cairnarvon. Cela ressemble àpylint --disable=bad-builtin. Répétez--disablepour supprimer les éléments supplémentaires.Désactive davantage les lignes de code Python individuelles, comme décrit par Imolit. Celles-ci ressemblent à
some statement # pylint: disable=broad-except(commentaire supplémentaire à la fin de la ligne d'origine) et s'applique uniquement à la ligne actuelle. Mon approche est de toujours les mettre à la fin des autres lignes de code afin qu'elles ne soient pas confondues avec le style de bloc, voir ci-dessous.D'autres désactivations sont définies pour les blocs plus importants de code Python, afin de compléter les fichiers source.
Celles-ci ressemblent à
# pragma pylint: disable=bad-whitespace(notez le mot clépragma.).Ces s'appliquent à chaque ligne après le pragma. En plaçant un bloc en haut d'un fichier, les suppressions s'appliquent à l'ensemble du fichier. En plaçant le même bloc plus bas dans le fichier, elles ne s'appliquent qu'aux lignes qui suivent le bloc. Mon approche est de toujours les mettre sur une ligne pour ne pas les confondre avec le style à une ligne, voir ci-dessus.
Lorsqu'une suppression ne doit s'appliquer que dans une plage de code, utilisez
# pragma pylint: enable=bad-whitespace(utilisez maintenantenableet nondisable) pour arrêter la suppression.
Notez que la désactivation pour une seule ligne utilise la syntaxe # pylint tandis que la désactivation ultérieure pour cette ligne utilise la syntaxe # pragma pylint. Celles-ci sont faciles à confondre, en particulier lors du copier-coller.
Tout mettre ensemble
J'utilise généralement un mélange de ces approches.
J'utilise
~/.pylintrcpour des normes absolument globales - très peu d'entre elles.J'utilise
pylintrcau niveau du projet à différents niveaux au sein des modules Python lorsqu'il existe des normes spécifiques au projet. En particulier lorsque vous récupérez du code provenant d'une autre personne ou d'une autre équipe, vous pouvez constater qu'ils utilisent des conventions que vous ne préférez pas, mais que vous ne souhaitez pas retravailler le code. Le fait de conserver les paramètres à ce niveau aide à ne pas diffuser ces pratiques à d’autres projets.J'utilise les pragmas de style de bloc au sommet des fichiers source uniques. J'aime désactiver les pragmas (arrêter de supprimer les messages) dans le feu du développement, même pour les standards Pylint avec lesquels je ne suis pas d'accord (comme "trop peu de méthodes publiques" - je reçois toujours cet avertissement sur les classes Exception personnalisées) - mais il est utile de voir plus/peut-être tous les messages Pylint pendant votre développement. De cette façon, vous pouvez trouver les cas que vous souhaitez traiter avec des pragmas sur une ligne (voir ci-dessous) ou simplement ajouter des commentaires au prochain développeur pour expliquer pourquoi cet avertissement est correct dans ce cas.
Je laisse certains pragmas de type bloc activés même lorsque le code est prêt à être archivé. J'essaie d'en utiliser quelques-uns, mais lorsque cela est logique pour le module, vous pouvez le faire en tant que documentation. Cependant, j'essaie d'en laisser le moins possible, de préférence aucune.
J'utilise le style de commentaire sur une seule ligne pour traiter les erreurs particulièrement puissantes. Par exemple, s'il y a un endroit où il est logique de faire
except Exception as exc, je mets le# pylint: disable=broad-exceptsur cette ligne au lieu d'une approche plus globale car il s'agit d'une exception étrange qui doit être appelée, essentiellement comme une forme de documentation.
Comme tout le reste en Python, vous pouvez agir à différents niveaux d'indirection. Mon conseil est de réfléchir à ce qui appartient à quel niveau afin de ne pas vous retrouver avec une approche trop indulgente envers Pylint.
Vous pouvez également utiliser la commande suivante:
pylint --disable=C0321 test.py
Ma version pylint est 0.25.1.
Ceci est un FAQ :
4.1 Est-il possible de désactiver localement un message particulier?
Oui, cette fonctionnalité a été ajoutée dans Pylint 0.11. Cela peut être fait en ajoutant
“# Pylint: disable = un message, un autre” au niveau du bloc souhaité ou à la fin de la ligne de code souhaitée.
Vous pouvez désactiver les messages par code ou par nom symbolique. Voir le docs (ou exécutez pylint --list-msgs dans le terminal) pour obtenir la liste complète des messages de pylint.
La documentation fournit également un Nice exemple d'utilisation de cette fonctionnalité.
Il vous suffit d'ajouter une ligne pour désactiver ce que vous voulez désactiver. Par exemple.
#pylint: disable = line-too-long, too-many-lines, no-name-in-module, import-error, multiple-imports, pointless-string-statement, wrong-import-order
Ajoutez ceci au # 1 de votre module
Si cela vous aide, si vous utilisez du code Visual Studio, le fichier doit être au format UTF8. Pour générer le fichier, j'ai exécuté pylint --generate-rcfile | out-file -encoding utf8 .pylintrc dans PowerShell.
La syntaxe Python autorise plusieurs instructions sur une ligne, séparées par un point-virgule (;). Cependant, le fait de limiter chaque ligne à une déclaration permet à un humain de suivre plus facilement la logique d'un programme lors de sa lecture.
Une autre façon de résoudre ce problème consiste donc à comprendre pourquoi le message de la charpie existe et à ne pas mettre plus d’une déclaration sur une ligne.
Oui, vous trouverez peut-être plus facile d'écrire plusieurs instructions par ligne. Cependant, pylint est destiné à tous les autres lecteurs de votre code et pas seulement à vous.