Comment désactiver un avertissement Pylint?


267

J'essaie de désactiver l'avertissement C0321 ("plusieurs instructions sur une seule ligne" - je mets souvent des ifinstructions avec de courts résultats sur une seule ligne sur la même ligne), dans Pylint 0.21.1 (si cela importe: astng 0.20. 1, commun 0.50.3, Python 2.6.6 (r266: 84292, 15 septembre 2010, 16:22:56)).

J'ai essayé d'ajouter disable=C0321le fichier de configuration Pylint, mais Pylint insiste pour le signaler quand même. Variations sur cette ligne (comme disable=0321ou disable=C321) sont signalés comme des erreurs, donc pylint ne reconnaît l'option correctement, il est tout simplement l' ignorer.

Est-ce un bug 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.


1
Il y a une bonne solution ici si vous souhaitez désactiver une seule ligne de code, pas toutes les erreurs d'un genre.
Le Droid

Réponses:


168

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=

Il semble donc que vous ~/.pylintrcdevriez avoir la disable=/ les ligne (s) dans une section [MESSAGES CONTROL].


1
Merci, mais c'est déjà le cas, dans la section [CONTRÔLE DES MESSAGES] comme indiqué ci-dessus. Toujours ignoré.
Head Geek

6
@Head Geek: eh bien, ça marche pour moi. ~/.pylintrcavec deux lignes, [MESSAGES CONTROL]et disable=C0321. Cela empêche ce message.
Chris Morgan

Bizarre ... exactement la même version de PyLint?
Head Geek

@Head Geek: 0.21.3, astng 0.20.3 et commun 0.52.1 en fait (le plus récent quand je l'ai installé, plus récent que le vôtre)
Chris Morgan

1
@ Chris Morgan: Ah. Probablement un bug qui a déjà été corrigé, alors - j'utilise la version du référentiel d'Ubuntu. Merci!
Head Geek

165

J'ai eu ce problème en utilisant Eclipse et je l'ai 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 et choisissez d'ouvrir la commande Windows dans ce dossier. Type:

lint.py --generate-rcfile > standard.rc

Cela crée le standard.rcfichier de configuration. Ouvrez-le dans le bloc-notes et sous [MESSAGES CONTROL], décommentez disable=et ajoutez les ID de message que vous souhaitez désactiver, par exemple:

disable=W0511, C0321

Enregistrez le fichier et dans Eclipse-> fenêtre-> préférences-> PyDev-> pylint, dans la zone d'arguments, tapez:

--rcfile=C:\Python26\Lib\site-packages\pylint\standard.rc

Maintenant ça devrait marcher ...


Vous pouvez également ajouter un commentaire en haut de votre code qui sera interprété par pylint:

# pylint: disable=C0321

lien vers tous les codes de message pylint


L'ajout, par exemple, --disable-ids=C0321dans la zone d'arguments ne fonctionne pas. Tous les messages Pylint disponibles sont stockés dans le dictionnaire _messages, un attribut d'une instance de la pylint.utils.MessagesHandlerMixInclasse. Lors de l'exécution de pylint avec l'argument --disable-ids=...(au moins sans fichier de configuration), ce dictionnaire est initialement vide, ce qui 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.)


2
Non, ça ne devrait vraiment pas. 1) Il fait référence à Eclipse, ce qui n'est pas pertinent pour la question posée. 2) Il recommande de désactiver les codes de message hérités. Je recommanderais ma réponse pour la solution la plus simple au problème, ou la réponse de Chris Johnson pour plus de détails.
imolit

153

À partir de Pylint v. 0.25.3, vous pouvez utiliser les noms symboliques pour désactiver les avertissements au lieu de devoir vous souvenir de 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 nouvelles versions de Pylint ne produisent 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 vient après dans le même bloc. Alternativement, il peut être inséré à la fin de la ligne pour laquelle il est censé s'appliquer.

Si les sorties de pylint « Locally disabling» messages, vous pouvez vous débarrasser d'eux en incluant le désactiver d' locally-disabled abord comme dans l'exemple ci - dessus.


20
Mais mettre # pylint: disable=fooinlyne me rend la ligne trop longue, alors maintenant je dois ajouter , line-too-long! La langue dans la joue; c'est ce dont j'avais besoin et résout mon problème. Merci!
dwanderson

Liste des chaînes réelles à utiliser: gist.github.com/m451/965bb613177dd4fa896b815aa0e0e365
masi

81

Pour désactiver un avertissement localement dans un bloc, ajoutez

# pylint: disable=C0321

à ce bloc.


5
Il s'agit d'une technique héritée et n'est plus recommandée. Voir les autres réponses.
Acumenus

1
Vous voulez dire qu'on devrait utiliser le nom symbolique au lieu du numéro de code, oui?
thakis

5
Oui. La réponse de imolit couvre exactement cela.
Acumenus

2
Comment trouve-t-on le nom symbolique? Mon éditeur va cracher [pylint] C0111: Missing method docstring, donc trouver le numéro de code est facile, mais trouver le nom symbolique signifie que je dois le rechercher.
Adam Parkin

@AdamParkin J'ai trouvé mes messages ici: pylint-messages.wikidot.com/all-messages
Jean-Francois T.

81

Il existe plusieurs façons de désactiver les avertissements et les erreurs de Pylint. Lequel utiliser a à voir avec la façon dont vous souhaitez appliquer la désactivation à l'échelle mondiale ou locale - une décision de conception importante.

Approches multiples

  1. Dans un ou plusieurs pylintrcfichiers.

Cela implique plus que le ~/.pylintrcfichier (dans votre répertoire $ HOME) tel que décrit par Chris Morgan. Pylint recherchera les fichiers rc, avec une priorité qui valorise les fichiers "plus proches" plus fortement:

  • Un pylintrcfichier dans le répertoire de travail courant; ou

  • Si le répertoire de travail actuel se trouve dans un module Python (c'est-à-dire qu'il contient un __init__.pyfichier), recherche dans la hiérarchie des modules Python jusqu'à ce qu'un pylintrcfichier soit trouvé; ou

  • Le 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 en ~a un premier point.

À votre pylintrcfichier, ajoutez des lignes pour désactiver des messages de pylônes spécifiques. Par exemple:

[MESSAGES CONTROL]
disable=locally-disabled
  1. Désactive en outre la pylintligne de commande, comme décrit par Aboo et Cairnarvon. Cela ressemble pylint --disable=bad-builtin. Répétez --disablepour supprimer les éléments supplémentaires.

  2. Désactive en outre des 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 source d'origine) et s'appliquent uniquement à la ligne actuelle . Mon approche est de toujours les mettre à la fin des autres lignes de code afin de ne pas les confondre avec le style de bloc, voir ci-dessous.

  3. Désactive en outre la définition des blocs de code Python plus volumineux, jusqu'aux fichiers source complets.

    • Celles-ci ressemblent # pragma pylint: disable=bad-whitespace(notez le pragmamot clé).

    • Celles-ci s'appliquent à chaque ligne après le pragma. Mettre un bloc de ceux-ci en haut d'un fichier fait que les suppressions s'appliquent à l'ensemble du fichier. Placer le même bloc plus bas dans le fichier les fait s'appliquer uniquement aux lignes suivant le bloc. Mon approche consiste à toujours les mettre sur une ligne qui leur est propre afin qu'ils ne soient pas confondus avec le style à une seule ligne, voir ci-dessus.

    • Lorsqu'une suppression ne doit s'appliquer que dans une plage de code, utilisez # pragma pylint: enable=bad-whitespace(maintenant en utilisant enablenot disable) pour arrêter la suppression.

Notez que la désactivation pour une seule ligne utilise la # pylintsyntaxe tandis que la désactivation pour cette ligne à partir de là utilise la # pragma pylintsyntaxe. Ceux-ci sont faciles à confondre, en particulier lors du copier-coller.

Mettre tous ensemble

J'utilise généralement un mélange de ces approches.

  • J'utilise ~/.pylintrcpour des normes absolument mondiales - très peu d'entre elles.

  • J'utilise pylintrcau niveau du projet à différents niveaux dans les modules Python lorsqu'il existe des normes spécifiques au projet. Surtout lorsque vous récupérez du code d'une autre personne ou équipe, vous pouvez trouver qu'ils utilisent des conventions que vous ne préférez pas, mais vous ne voulez pas retravailler le code. Le maintien des paramètres à ce niveau permet de ne pas diffuser ces pratiques à d'autres projets.

  • J'utilise les pragmas de style bloc en haut des fichiers source uniques. J'aime désactiver les pragmas (arrêtez de supprimer les messages) pendant le développement, même pour les normes Pylint avec lesquelles je ne suis pas d'accord (comme "trop ​​peu de méthodes publiques" - je reçois toujours cet avertissement sur les classes d'exception personnalisées) - mais il est utile de voir plus / peut-être tous les messages Pylint pendant que vous développez. De cette façon, vous pouvez trouver les cas que vous souhaitez résoudre avec des pragmas sur une seule ligne (voir ci-dessous), ou simplement ajouter des commentaires pour le prochain développeur pour expliquer pourquoi cet avertissement est OK dans ce cas.

  • Je laisse certains pragmas de style bloc activés même lorsque le code est prêt à être archivé. J'essaie d'en utiliser quelques-uns, mais quand cela a du sens pour le module, c'est OK de le faire comme documentation. Cependant j'essaye d'en laisser le moins possible, de préférence aucune.

  • J'utilise le style de commentaire sur une seule ligne pour corriger les erreurs particulièrement puissantes. Par exemple, s'il y a un endroit où cela a du sens except Exception as exc, je mets le # pylint: disable=broad-exceptsur cette ligne au lieu d'une approche plus globale car c'est une étrange exception et 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 penser à ce qui appartient à quel niveau afin de ne pas vous retrouver avec une approche trop clémente de Pylint.


1
Meilleure réponse, similaire à stackoverflow.com/questions/16266452/…
Christophe Roussy

1
Pour la plupart, je ne peux pas préconiser l'utilisation d'un non vide mondial ~/.pylintrc. À mon humble avis, la configuration doit généralement être liée au projet, et donc elle doit être quelque part dans le projet. Ce n'est qu'alors que la version peut être contrôlée et partagée avec le projet. A défaut, un clone peut ne pas avoir les personnalisations nécessaires pour que pylint se termine sans imprimer de messages.
Acumenus

@ABB Je pense que c'est sage
Chris Johnson

3
@ChrisJohnson Le préfixe pragma semble totalement inutile. Par exemple, j'ai # pylint: disable=missing-docstringen haut de mon fichier, et cela s'applique à tout le reste du fichier. Veuillez vérifier et supprimer le pragmapréfixe de votre réponse.
Acumenus

La FAQ Pylint n'écrit sur aucun pragma. ( pylint.pycqa.org/en/latest/… ): vous pouvez désactiver ou activer les messages (globalement désactivés) au niveau du module en ajoutant l'option correspondante dans un commentaire en haut du fichier: # pylint: disable = wildcard- import, méthode cachée # pylint: enable = too-many-lines
Yaroslav Nikitenko

19

Vous pouvez également utiliser la commande suivante:

pylint --disable=C0321  test.py

Ma version pylint est 0.25.1.


Il s'agit désormais d'une technique héritée. Il est recommandé d'utiliser à la place le nom symbolique de l'avertissement désactivé. Voir cette réponse .
Acumenus

Cela ne semble pas fonctionner non plus avec le --py3kdrapeau :(
DylanYoung

Chose intéressante, cela fonctionne très bien s'il est fourni dans le rcfichier et (plus troublant), il génère en fait un rcfichier correct avec --generate-rcfile. Je dois aimer le code avec plusieurs branches qui font la même chose :(
DylanYoung

18

Ceci est une 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=some-message,another-oneau niveau de bloc souhaité ou à la fin de la ligne de code souhaitée.

4.2 Existe-t-il un moyen de désactiver un message pour un module particulier uniquement?

Oui, vous pouvez désactiver ou activer les messages (globalement désactivés) au niveau du module en ajoutant l'option correspondante dans un commentaire en haut du fichier:

# pylint: disable=wildcard-import, method-hidden
# pylint: enable=too-many-lines

Vous pouvez désactiver les messages en:

  • ID numérique: E1101, E1102etc.
  • message symbolique: no-member, undefined-variableetc.
  • le nom d'un groupe de chèques. Vous pouvez les saisir avec pylint --list-groups.
  • catégorie de chèques: C, R, W, etc.
  • tous les chèques avec all.

Consultez la documentation (ou exécutez-la pylint --list-msgsdans le terminal) pour la liste complète des pylintmessages de. Les documents fournissent également un bel exemple de la façon d'utiliser cette fonctionnalité.


5

Il vous suffit d'ajouter une ligne pour désactiver ce que vous souhaitez 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 dans votre module


4

Si cela aide quelqu'un, si vous utilisez Visual Studio Code, il s'attend à ce que le fichier soit au format UTF8. Pour générer le fichier, j'ai couru pylint --generate-rcfile | out-file -encoding utf8 .pylintrcdans PowerShell.


0

Selon la documentation de pylint , le plus simple est d'utiliser ce tableau :

  • Contrôles liés à la convention C
  • R refactorisation des chèques associés
  • W divers avertissements
  • Erreurs E, pour des bogues probables dans le code
  • F fatal, si une erreur s'est produite qui a empêché Pylint de poursuivre le traitement.

On peut donc utiliser:

pylint -j 0 --disable=I,E,R,W,C,F YOUR_FILES_LOC

-1

La syntaxe Python autorise plusieurs instructions sur une ligne, séparées par un point-virgule (;). Cependant, limiter chaque ligne à une seule instruction permet à un humain de suivre plus facilement la logique d'un programme lors de sa lecture.

Donc, une autre façon de résoudre ce problème est de comprendre pourquoi le message sur les peluches est là et de ne pas mettre plus d'une déclaration sur une ligne.

Oui, vous pouvez trouver plus facile d'écrire plusieurs instructions par ligne, cependant, pylint est destiné à tous les autres lecteurs de votre code et pas seulement à vous.


-1

Vous voudrez peut-être essayer ceci:

Modifiez "C: \ Users \ Your User \ AppData \ Roaming \ Code \ User \ settings.json" et ajoutez des python.linting.pylintArgslignes à la fin comme indiqué ci-dessous:

{
    "team.showWelcomeMessage": false,
    "python.dataScience.sendSelectionToInteractiveWindow": true,
    "git.enableSmartCommit": true,
    "powershell.codeFormatting.useCorrectCasing": true,
    "files.autoSave": "onWindowChange",
    "python.linting.pylintArgs": [
        "--load-plugins=pylint_django",
        "--errors-only"
    ],
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.