Wie kann ich eine Pylint-Warnung deaktivieren?

Question

Ich versuche, die Warnung C0321 ("mehr als eine Anweisung in einer Zeile") zu deaktivieren - ich setze oft if Anweisungen mit kurzen einzeiligen Ergebnissen in derselben Zeile), in Pylint 0.21.1 (falls es von Bedeutung ist: astng 0.20.1, common 0.50.3 und Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)).

Ich habe versucht, Folgendes hinzuzufügen disable=C0321 in der Pylint-Konfigurationsdatei, aber Pylint besteht darauf, es trotzdem zu melden. Variationen dieser Zeile (wie disable=0321 o disable=C321 ) werden als Fehler gekennzeichnet, so dass Pylint tut die Option richtig erkennen. Sie wird einfach ignoriert.

Ist dies ein Fehler in Pylint, oder mache ich etwas falsch? Gibt es eine Möglichkeit, dies zu umgehen?

Ich würde gerne etwas von diesem Lärm loswerden.

Answer 1

Ab Pylint v. 0.25.3 können Sie die symbolischen Namen zum Deaktivieren von Warnungen verwenden statt sich all diese Codenummern merken zu müssen . Z.B.:

# pylint: disable=locally-disabled, multiple-statements, fixme, line-too-long

Dieser Stil ist aufschlussreicher als kryptische Fehlercodes und auch praktischer, da neuere Versionen von Pylint nur den symbolischen Namen und nicht den Fehlercode ausgeben.

Die Korrespondenz zwischen symbolischen Namen und Codes kann gefunden werden aquí .

Ein Deaktivierungskommentar kann in eine eigene Zeile eingefügt werden, so dass die Deaktivierung für alles gilt, was im selben Block folgt. Alternativ kann er auch am Ende der Zeile eingefügt werden, für die er gelten soll.

Wenn Pylint ausgibt " Locally disabling "Meldungen können Sie loswerden, indem Sie die Option disable locally-disabled primero wie im obigen Beispiel.

Answer 2

pylint --generate-rcfile zeigt es so:

[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=

Es sieht also so aus, als ob Ihr ~/.pylintrc sollte die disable= Zeile/n innerhalb eines Abschnitts [MESSAGES CONTROL] .

Answer 3

Ich hatte dieses Problem mit Eclipse und löste sie wie folgt:

In der Pylint-Ordner (z.B.. C:\Python26\Lib\site-packages\pylint ), halten Shift klicken Sie mit der rechten Maustaste und wählen Sie den Windows-Befehl in diesem Ordner öffnen. Tippen Sie:

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

Dadurch wird die standard.rc Konfigurationsdatei. Öffnen Sie sie in Notepad und unter [MESSAGES CONTROL] , unkommentiert disable= und fügen Sie die Nachrichten-IDs hinzu, die Sie deaktivieren möchten, z. B:

disable=W0511, C0321

Speichern Sie die Datei, und in Eclipse Fenster Präferenzen PyDev *pylint, geben Sie in das Feld Argumente ein:

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

Jetzt sollte es funktionieren...

---

Sie können auch einen Kommentar hinzufügen am Anfang Ihres Codes, der von Pylint interpretiert werden soll:

# pylint: disable=C0321

---

Pylint-Meldungscodes .

---

Hinzufügen von z.B. --disable-ids=C0321 in der Argumentationsbox funktioniert nicht.

Alle verfügbaren Pylint-Meldungen werden im Wörterbuch gespeichert _messages , ein Attribut einer Instanz der pylint.utils.MessagesHandlerMixIn Klasse. Wenn Sie Pylint mit dem Argument --disable-ids=... (zumindest ohne Konfigurationsdatei), ist dieses Wörterbuch anfangs leer, was eine KeyError-Ausnahme in Pylint auslöst ( pylint.utils.MessagesHandlerMixIn.check_message_id() .

In Eclipse können Sie diese Fehlermeldung in der Pylint-Konsole sehen (Windows* Ansicht anzeigen Konsole wählen Sie Pylint-Konsole aus den Konsolenoptionen neben dem Konsolensymbol).

Answer 4

Um eine Warnung lokal in einem Block zu deaktivieren, fügen Sie

# pylint: disable=C0321

zu diesem Block.

Answer 5

Es gibt mehrere Möglichkeiten, Warnungen und Fehler von Pylint zu deaktivieren. Welche Sie verwenden, hat damit zu tun, wie global oder lokal Sie die Deaktivierung anwenden wollen - eine wichtige Designentscheidung.

Mehrere Ansätze

1. In einem oder mehreren pylintrc Dateien.

Dazu gehört mehr als die ~/.pylintrc Datei (in Ihrem $HOME-Verzeichnis), wie von Chris Morgan beschrieben. Pylint sucht nach rc-Dateien, wobei "nähere" Dateien höher bewertet werden:

• A pylintrc Datei im aktuellen Arbeitsverzeichnis; oder

• Befindet sich das aktuelle Arbeitsverzeichnis in einem Python-Modul (d.h. es enthält ein __init__.py Datei), die die Hierarchie der Python-Module durchsucht, bis ein pylintrc Datei gefunden wird; oder

• die durch die Umgebungsvariable PYLINTRC benannte Datei; oder

• Wenn Sie ein Home-Verzeichnis haben, das nicht /root :

  • ~/.pylintrc ; oder

  • ~/.config/pylintrc ; oder

  • /etc/pylintrc

Beachten Sie, dass die meisten dieser Dateien den Namen pylintrc -- nur die Datei in ~ hat einen führenden Punkt.

Zu Ihrem pylintrc fügen Sie Zeilen hinzu, um bestimmte Pylint-Meldungen zu deaktivieren. Zum Beispiel:

[MESSAGES CONTROL]
disable=locally-disabled

2. Weitere Deaktivierungen aus dem pylint Befehlszeile, wie von Aboo und Cairnarvon beschrieben. Das sieht dann so aus pylint --disable=bad-builtin . Wiederholen Sie --disable um zusätzliche Einträge zu unterdrücken.

3. Weitere Deaktivierungen von einzelnen Python-Codezeilen, wie von Imolit beschrieben. Diese sehen aus wie some statement # pylint: disable=broad-except (zusätzlicher Kommentar am Ende der ursprünglichen Quellzeile) und gelten nur für die aktuelle Zeile . Mein Ansatz ist es, diese immer am Ende anderer Codezeilen zu platzieren, damit sie nicht mit dem Blockstil verwechselt werden, siehe unten.

4. Weitere Deaktivierungen sind für größere Blöcke von Python-Code definiert, bis hin zu kompletten Quelldateien.

   • Diese sehen aus wie # pragma pylint: disable=bad-whitespace (Beachten Sie die pragma Schlüsselwort).

   • Diese gelten für jede Zeile nach das Pragma. Wenn Sie einen solchen Block an den Anfang einer Datei setzen, gelten die Unterdrückungen für die gesamte Datei. Wird derselbe Block weiter unten in der Datei eingefügt, gelten sie nur für die auf den Block folgenden Zeilen. Mein Ansatz ist es, diese Unterdrückungen immer in eine eigene Zeile zu setzen, damit sie nicht mit dem einzeiligen Stil verwechselt werden können (siehe oben).

   • Wenn eine Unterdrückung nur innerhalb einer Code-Spanne gelten soll, verwenden Sie # pragma pylint: enable=bad-whitespace (jetzt mit enable no disable ), um die Unterdrückung zu beenden.

Beachten Sie, dass die Deaktivierung für eine einzelne Zeile mit dem # pylint Syntax, während die Deaktivierung ab dieser Zeile mit der # pragma pylint Syntax. Diese sind vor allem beim Kopieren und Einfügen leicht zu verwechseln.

Alles zusammenfügen

Ich verwende in der Regel eine Mischung aus diesen Ansätzen.

• を使っています。 ~/.pylintrc für absolut globale Standards - sehr wenige davon.

• Ich verwende die Projektebene pylintrc auf verschiedenen Ebenen innerhalb von Python-Modulen, wenn es projektspezifische Standards gibt. Vor allem wenn Sie Code von einer anderen Person oder einem anderen Team übernehmen, kann es vorkommen, dass diese Konventionen verwenden, die Sie nicht bevorzugen, aber Sie wollen den Code nicht überarbeiten. Die Beibehaltung der Einstellungen auf dieser Ebene hilft, diese Praktiken nicht auf andere Projekte zu übertragen.

• Ich verwende die blockartigen Pragmas am Anfang der einzelnen Quelldateien. In der Hitze der Entwicklung schalte ich die Pragmas gerne aus (unterdrücke keine Meldungen mehr), selbst bei Pylint-Standards, mit denen ich nicht einverstanden bin (wie "zu wenige öffentliche Methoden" - diese Warnung erhalte ich immer bei benutzerdefinierten Exception-Klassen) - aber es ist hilfreich, mehr / vielleicht alle Pylint-Meldungen zu sehen, während man entwickelt. Auf diese Weise können Sie die Fälle finden, die Sie mit einzeiligen Pragmas (siehe unten) angehen wollen, oder einfach Kommentare für den nächsten Entwickler hinzufügen, um zu erklären, warum diese Warnung in diesem Fall OK ist.

• Ich lasse einige der blockartigen Pragmas aktiviert, auch wenn der Code zum Einchecken bereit ist. Ich versuche, nur wenige davon zu verwenden, aber wenn es für das Modul Sinn macht, ist es in Ordnung, es als Dokumentation zu tun. Ich versuche jedoch, so wenig wie möglich aktiviert zu lassen, vorzugsweise gar keine.

• Ich verwende den einzeiligen Kommentarstil, um besonders starke Fehler anzusprechen. Wenn es zum Beispiel eine Stelle gibt, an der es tatsächlich sinnvoll ist, Folgendes zu tun except Exception as exc habe ich die # pylint: disable=broad-except in dieser Zeile anstelle eines globaleren Ansatzes, da es sich um eine merkwürdige Ausnahme handelt, die im Grunde als eine Art Dokumentation herausgestellt werden muss.

---

Wie alles andere in Python können Sie auf verschiedenen Ebenen der Indirektion agieren. Mein Rat ist, darüber nachzudenken, was auf welche Ebene gehört, damit Sie nicht mit einem zu einfachen Ansatz für Pylint enden.