Come disabilitare un avviso Pylint?

Sto provando a disabilitare l'avvertimento C0321 ("più di un'istruzione su una sola riga" - metto spesso ifdichiarazioni con risultati a riga singola sulla stessa riga), in Pylint 0.21.1 (se conta: 0,20. 1, comune 0.50.3, Python 2.6.6 (r266: 84292, 15 settembre 2010, 16:22:56)).

Ho provato ad aggiungere disable=C0321il file di configurazione di Pylint, ma Pylint insiste a segnalarlo comunque. Le variazioni su quella riga (come disable=0321o disable=C321) sono contrassegnate come errori, così fa Pylint riconoscere l'opzione corretta, è solo ignorarlo.

È un bug di Pylint o sto facendo qualcosa di sbagliato? C'è un modo per aggirare questo? Mi piacerebbe davvero sbarazzarmi di questo rumore.

pylint --generate-rcfile lo mostra in questo modo:

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

Quindi sembra che ~/.pylintrcdovresti avere le disable=linee all'interno di una sezione [MESSAGES CONTROL].

Ho avuto questo problema con Eclipse e l'ho risolto come segue:

nella cartella Pylint (ad es. C:\Python26\Lib\site-packages\pylint), tieni premuto MAIUSC, fai clic con il pulsante destro del mouse e scegli di aprire il comando Windows in quella cartella. Genere:

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

Questo crea il standard.rcfile di configurazione. Aprilo nel blocco note e sotto [MESSAGES CONTROL], decommenta disable=e aggiungi l'ID del messaggio che vuoi disabilitare, ad esempio:

disable=W0511, C0321

Salvare il file e in Eclipse-> finestra-> preferenze-> PyDev-> pylint, nella casella argomenti, digitare:

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

Ora dovrebbe funzionare ...

Puoi anche aggiungere un commento nella parte superiore del codice che verrà interpretato da Pylint:

# pylint: disable=C0321

collegamento a tutti i codici dei messaggi Pylint

L'aggiunta, ad esempio, --disable-ids=C0321nella casella degli argomenti non funziona. Tutti i messaggi pylint disponibili sono memorizzati nel dizionario _messages, un attributo di un'istanza della pylint.utils.MessagesHandlerMixInclasse. Quando si esegue pylint con l'argomento --disable-ids=...(almeno senza un file di configurazione), questo dizionario è inizialmente vuoto, sollevando un'eccezione KeyError all'interno di pylint ( pylint.utils.MessagesHandlerMixIn.check_message_id(). In Eclipse, è possibile visualizzare questo messaggio di errore nella Console Pylint (windows - show view - Console , seleziona Console Pylint dalle opzioni della console oltre all'icona della console.)

A partire da Pylint v. 0.25.3, è possibile utilizzare i nomi simbolici per disabilitare gli avvisi invece di dover ricordare tutti quei numeri di codice . Per esempio:

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

Questo stile è più istruttivo dei codici di errore criptici e anche più pratico poiché le versioni più recenti di Pylint producono solo il nome simbolico, non il codice di errore.

La corrispondenza tra nomi simbolici e codici può essere trovata qui .

Un commento di disabilitazione può essere inserito sulla propria riga, applicando la disabilitazione a tutto ciò che viene dopo nello stesso blocco. In alternativa, può essere inserito alla fine della riga a cui è destinato.

Se pylint genera " Locally disabling" messaggi, puoi eliminarli includendo locally-disabled prima la disabilitazione come nell'esempio sopra.

Per disabilitare un avviso localmente in un blocco, aggiungere

# pylint: disable=C0321

a quel blocco.

Esistono diversi modi per disabilitare avvisi ed errori da Pylint. Quale da utilizzare ha a che fare con il modo in cui a livello globale o locale si desidera applicare la disabilitazione, una decisione di progettazione importante.

Approcci multipli

1. In uno o più pylintrcfile.

Ciò implica più del ~/.pylintrcfile (nella directory $ HOME) come descritto da Chris Morgan. Pylint cercherà i file rc, con una precedenza che valorizza i file "più vicini" in modo più elevato:

• Un pylintrcfile nella directory di lavoro corrente; o

• Se la directory di lavoro corrente si trova in un modulo Python (ovvero contiene un __init__.pyfile), cerca nella gerarchia dei moduli Python fino a quando non pylintrcviene trovato un file; o

• Il file denominato dalla variabile di ambiente PYLINTRC; o

• Se hai una home directory che non lo è /root:

  • ~/.pylintrc; o

  • ~/.config/pylintrc; o

  • /etc/pylintrc

Nota che la maggior parte di questi file ha un nome pylintrc: solo il file ~ha un punto iniziale.

Al tuo pylintrcfile, aggiungi linee per disabilitare specifici messaggi di pylint. Per esempio:

[MESSAGES CONTROL]
disable=locally-disabled

2. Ulteriori disabilita dalla pylintriga di comando, come descritto da Aboo e Cairnarvon. Questo sembra pylint --disable=bad-builtin. Ripetere l'operazione --disableper eliminare ulteriori elementi.

3. Ulteriori disabilitazioni dalle singole righe di codice Python, come descritto da Imolit. Sembrano simili some statement # pylint: disable=broad-except(commento extra alla fine della riga di origine originale) e si applicano solo alla riga corrente . Il mio approccio è quello di metterli sempre alla fine di altre righe di codice in modo che non vengano confusi con lo stile del blocco, vedi sotto.

4. Ulteriori disabilitazioni definite per blocchi più grandi di codice Python, fino al completamento dei file sorgente.

   • Questi sembrano # pragma pylint: disable=bad-whitespace(nota la pragmaparola chiave).

   • Questi si applicano ad ogni riga dopo il pragma. Inserendo un blocco di questi nella parte superiore di un file, le soppressioni si applicano all'intero file. Mettere lo stesso blocco più in basso nel file li fa applicare solo alle linee che seguono il blocco. Il mio approccio è quello di metterli sempre su una linea propria in modo che non vengano confusi con lo stile a linea singola, vedi sopra.

   • Quando una soppressione dovrebbe applicarsi solo in un arco di codice, utilizzare # pragma pylint: enable=bad-whitespace(ora enablenon utilizzando disable) per interrompere la soppressione.

Si noti che la disabilitazione per una singola riga utilizza la # pylintsintassi mentre la disabilitazione per questa riga in poi utilizza la# pragma pylint sintassi. Questi sono facili da confondere soprattutto quando si copia e incolla.

Mettere tutto insieme

Di solito uso un mix di questi approcci.

• Uso ~/.pylintrcper standard assolutamente globali - pochissimi di questi.

• Uso i livelli di progetto pylintrca diversi livelli all'interno dei moduli Python quando esistono standard specifici del progetto. Soprattutto quando stai acquisendo codice da un'altra persona o team, potresti scoprire che usano convenzioni che non preferisci, ma non vuoi rielaborare il codice. Mantenere le impostazioni a questo livello aiuta a non diffondere tali pratiche ad altri progetti.

• Uso i pragmi in stile blocco nella parte superiore dei file a sorgente singolo. Mi piace disattivare i pragmi (smettere di sopprimere i messaggi) nel vivo dello sviluppo anche per gli standard di Pylint con cui non sono d'accordo (come "troppo pochi metodi pubblici" - Ricevo sempre quell'avvertimento sulle classi di eccezione personalizzate) - ma è utile vedere più / forse tutti i messaggi Pylint durante lo sviluppo. In questo modo puoi trovare i casi che vuoi affrontare con pragmi a riga singola (vedi sotto), o semplicemente aggiungere commenti per il prossimo sviluppatore per spiegare perché questo avviso è OK in questo caso.

• Lascio alcuni dei pragmi in stile blocco abilitati anche quando il codice è pronto per il check-in. Provo a usarne alcuni, ma quando ha senso per il modulo, va bene fare come documentazione. Comunque provo a lasciarne il meno possibile, preferibilmente nessuno.

• Uso lo stile di commento a riga singola per affrontare errori particolarmente potenti. Ad esempio, se c'è un posto in cui ha davvero senso fare except Exception as exc, metto # pylint: disable=broad-exceptsu quella linea invece di un approccio più globale perché questa è una strana eccezione e deve essere chiamata, fondamentalmente come una forma di documentazione.

Come tutto il resto in Python, puoi agire a diversi livelli di indiretta. Il mio consiglio è di pensare a ciò che appartiene a quale livello in modo da non finire con un approccio troppo indulgente a Pylint.

Puoi anche usare il seguente comando:

pylint --disable=C0321  test.py

La mia versione di pylint è la 0.25.1.

Questa è una FAQ :

4.1 È possibile disabilitare localmente un determinato messaggio?

Sì, questa funzione è stata aggiunta in Pylint 0.11. Questo può essere fatto aggiungendo
# pylint: disable=some-message,another-oneal livello di blocco desiderato o alla fine della riga di codice desiderata.

4.2 Esiste un modo per disabilitare un messaggio solo per un determinato modulo?

Sì, puoi disabilitare o abilitare i messaggi (disabilitati globalmente) a livello di modulo aggiungendo l'opzione corrispondente in un commento nella parte superiore del file:

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

Puoi disabilitare i messaggi:

• ID numerico: E1101,E1102 etc.
• messaggio simbolico: no-member, undefined-variableetc.
• il nome di un gruppo di assegni. Puoi afferrare quelli con pylint --list-groups.
• categoria di controlli: C, R,W , etc.
• tutti i controlli con all.

Vedi i documenti (o esegui pylint --list-msgsnel terminale) per l'elenco completo dei pylintmessaggi. I documenti forniscono anche un bell'esempio di come utilizzare questa funzione.

Devi solo aggiungere una riga per disabilitare ciò che vuoi disabilitare. Per esempio

#pylint: disable = line-too-long, too-many-lines, no-name-in-module, import-error, multiple-imports, pointless-string-statement, wrong-import-order

Aggiungi questo al numero 1 nel tuo modulo

Nel caso in cui ciò aiuti qualcuno, se stai usando Visual Studio Code, si aspetta che il file sia nella codifica UTF8. Per generare il file, ho eseguito pylint --generate-rcfile | out-file -encoding utf8 .pylintrcin PowerShell.

Secondo la documentazione di Pylint , il più semplice è usare questo grafico :

• Controlli relativi alla convenzione C.
• R controlli relativi al refactoring
• W vari avvertimenti
• E errori, per probabili bug nel codice
• F fatale, se si è verificato un errore che ha impedito al pylint di eseguire ulteriori elaborazioni.

Quindi si può usare:

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

La sintassi di Python consente più di un'istruzione su una riga, separata da punto e virgola (;). Tuttavia, limitare ogni riga a un'istruzione rende più facile per un essere umano seguire la logica di un programma durante la lettura.

Quindi, un altro modo di risolvere questo problema è capire perché il messaggio lanugine è presente e non mettere più di una frase su una riga.

Sì, potresti trovare più semplice scrivere più istruzioni per riga, tuttavia, pylint è per ogni altro lettore del tuo codice non solo per te.

Potresti provare questo:

Modifica "C: \ Users \ Your User \ AppData \ Roaming \ Code \ User \ settings.json" e aggiungi le python.linting.pylintArgsrighe alla fine come mostrato di seguito:

{
    "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"
    ],
}