Dovrei davvero usare tutte le maiuscole per le mie costanti?

Probabilmente stai scrivendo un codice come questo:

notes_director = argv[1]
chdir(notes_director)
files = glob('*.txt')
rand_file = choice(files)
with open(rand_file) as notes_file: 
    points = notes_file.readlines() 
    rand_point = choice(points)

Dovresti spostare questo codice in una funzione:

def main():
    notes_director = argv[1]
    chdir(notes_director)
    files = glob('*.txt')
    rand_file = choice(files)
    with open(rand_file) as notes_file: 
        points = notes_file.readlines() 
        rand_point = choice(points)

# actually call the main function    
main()

Pylint assume quel codice che effettivamente fa il lavoro all'interno di una funzione. Perché hai questo codice al livello più alto del tuo codice invece che all'interno di una funzione che viene confuso.

In generale, è meglio che lo stile funzioni all'interno di una funzione anziché al livello più alto. Ciò ti consente di organizzare meglio ciò che stai facendo e facilita il riutilizzo. Dovresti davvero avere codice che esegue un algoritmo al di fuori di una funzione in uno script veloce e sporco.

Sì. In base alla regola PEP8s su costanti :

Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.

Versione lunga:

Nella comunità Python (come in molte altre comunità) esistono convenzioni su come scrivere codice. Questo è diverso da codice di lavoro : anche se scrivi le tue costanti tutte in minuscolo, il tuo codice funziona ancora.

Ma c'è consenso della comunità (come documentato in PEP8) che è "forzato" con strumenti come pylint . Se si programma per la propria felicità, si può trascurare il suggerimento che l'addetto fornisce. Se vuoi uno scambio aperto con la community, alias »qualcuno oltre a me dovrebbe usare il mio codice«, dovresti preparare il tuo codice in base a PEP8.

La norma della community PEP8 e Python è di usare ALL_CAPS_CONSTANTS . È un indizio visivo comune, utilizzato da decenni in C, Java, Perl, PHP, Python, bash e altri linguaggi di programmazione e ambienti di shell. Ma nella moderna parlance online, TUTTI I CAPPELLI SIGNIFICA GRIDANO . E urlare è maleducato.

Python, tuttavia, è piuttosto incoerente su ALL_CAPS_CONSTANTS . JavaScript può avere Math.PI , ma Python ha math.pi . Non esiste una costante più riconoscibile o duratura di π. Oppure considera sys.version_info , la versione di Python su cui stai lavorando. Costante al 100% per tutta la durata del tuo programma: molto più di PORT o MAX_ITERATIONS o altre costanti che definiresti. O che dire di sys.maxsize ? Il valore intero nativo massimo della piattaforma è costante non solo su una o due esecuzioni del programma, ma sulla durata dell'hardware.

Se queste costanti - inclusi alcuni come π ed e che sono costanti fondamentali dell'universo, e non variano per tutta l'eternità - se loro possono essere minuscole, beh ... così può altre costanti. Puoi scegliere.

Ricorda che PEP8 è una guida di stile. Una linea guida, non una legge. Una linea guida spesso è stata violata anche dalla libreria standard di Python. E cita un'altra fondamentale linea guida di Python, PEP20 (aka "The Zen of Python"):

• Bello è meglio di brutto
• La leggibilità conta
• La praticità batte la purezza.

Da un punto di vista pratico, quando YELLY_CONSTANT e SHOUTY_PARAMETER di un programma iniziano a grattare, è utile ricordare che le costanti tutte maiuscole in genere non sono realmente resistenti a Ideali platonici , ma i parametri di un programma sono in esecuzione. Non c'è nulla di veramente costante in PORT , SITENAME o NUMRUNS , e non devono essere gestiti come globali di programmi standalone. Ad esempio, possono essere rilasciati in un dizionario come un pacchetto accessibile a livello globale di parametri del programma:

config = {
    'port': 80,
    'sitename': "Bubba's Blog",
    'numruns': 100,
}

Python ha anche una funzione di passaggio dei parametri di parole chiave che riduce la necessità di usare APPARENTLY_ANGRY_GLOBAL_VARIABLES :

def process_data(sitename, port=80, numruns=100):
    ...

process_data("Bubba's Blog")

In pratica, molti di questi valori saranno (o dovrebbero essere) letti dai file di configurazione, dalle variabili d'ambiente del SO, dagli argomenti della riga di comando o da altre fonti per soddisfare inversione del controllo principio / modello. Ma questa è una storia più grande per un altro giorno.

Sì, è abbastanza comune nella maggior parte del linguaggio di programmazione (almeno quelli che uso).

Puoi fare riferimento a questo link Google per condividere un comune stile tra gli sviluppatori dello stesso team.

Si consiglia di usare

Type                  |Public          |Internal
Global/Class Constants|CAPS_WITH_UNDER |_CAPS_WITH_UNDER