Lezioni dallo Zen di Python

Che cos'è lo Zen di Python? 

Lo Zen di Python è un insieme di diciannove aforismi che fungono da principi guida per la progettazione di Python. In realtà dovevano essere venti; ma Guido van Rossum, il creatore di Python, non ha ancora aggiunto l'aforisma finale come inteso da Tim Peters, l'autore dello Zen di Python. Guido avrebbe dichiarato che il ventesimo aforisma mancante è "una qualche bizzarra battuta interna di Tim Peters".

Nonostante il ventesimo aforisma mancante, lo Zen di Python è stato standardizzato come PEP 20 nel 2004 a causa della sua forte influenza sul processo di sviluppo dei programmatori Python. Seguire lo Zen di Python non è obbligatorio, ma conoscerlo e tenerlo a mente è consigliato. Se mai dovessi dimenticare le lezioni, puoi rinfrescarti la memoria eseguendo import this dall'interprete Python. 

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

In questo articolo, vedremo ciascuna lezione più nel dettaglio. 

#1 Bello è meglio che brutto 

Se sei un programmatore, non c'è dubbio che tu sia molto competente. Saper risolvere problemi con il codice non è un compito semplice, ma da Pythonista ci si aspetta di più. Il codice bello è meglio del codice brutto. La rapida ascesa alla fama di Python è dovuta in parte alla sua accessibilità: è semplice, leggibile ed elegante. Come sviluppatore Python, hai la responsabilità di mantenere lo standard pythonico scrivendo codice bello. 

Cos'è un codice bello? Beh, è soggettivo: la bellezza è negli occhi di chi guarda e via dicendo. Una regola pratica per tenerti in riga è scrivere codice pulito e leggibile, che altri sviluppatori possano capire facilmente. Per esempio: 

"""
Initial code was created by Vishal Sharma
See:  https://towardsdatascience.com/the-zen-of-python-a-guide-to-pythons-design-principles-93f3f76d088a
"""
def collatz(num):
    if num % 2 == 0:
        return num // 2
    else:
        return 3 * num + 1

number = input("Enter a number: ")

while number != 1:
    number = collatz(int(number))
    print(number)

"""
Enter a number: 5
16
8
4
2
1
"""

Il codice sopra funziona perfettamente, ma non è necessariamente bello. Abbiamo una condizione else non necessaria nella funzione collatz che può essere rimossa così: 

def collatz(num):
  if num % 2 == 0:
      return num // 2
 
  return 3 * num + 1

Quindi, quando ti trovi davanti a due porzioni di codice entrambe funzionanti, scegli quella più semplice, leggibile e facile da capire. 

#2 Esplicito è meglio che implicito

Spiegare un aforisma dicendo che è "autoesplicativo" è un grande errore - eppure vedrai comunque gente farlo. L'idea di fondo dietro "esplicito è meglio che implicito" è che il codice verboso è preferibile a quello indiretto. Fai tutto il possibile per garantire che la funzionalità del tuo codice non sia nascosta dietro un linguaggio oscuro. Qualcuno senza conoscenza pregressa del tuo programma dovrebbe comunque riuscire a capire cosa sta succedendo nel tuo codice. 

#3 Semplice è meglio che complesso

Probabilmente rideresti se un amico tirasse fuori un'idropulitrice per lavare i piatti dopo cena. Non solo è una soluzione estremamente sciocca, ma c'è anche un'alta probabilità che i piatti si rovinino. Allo stesso modo, applicare una soluzione molto complessa a un problema di programmazione semplice è estremamente poco pratico. Non c'è bisogno di complicare troppo la soluzione, anche se pensi che ti faccia sembrare intelligente. Potresti fare più danni che altro, e in Python non è apprezzato. 

Guarda questa funzione usata per invertire una stringa: 

def reverse_string(string):
    if len(string) == 1:
        return string
    else:
        return reverse_string(string[1:]) + string[0]


string = "kurtis"

print(reverse_string(string))

"""
sitruk
"""

Il codice sopra risolve sicuramente il problema ma è inutilmente complesso. Se hai una buona padronanza di Python, sai che una stringa può essere invertita con l'indicizzazione. 

string = "kurtis"

# annonymous function solution
reverse_string = lambda x: x[::-1]

# function solution
def reverse(string):
    return string[::-1]

print(reverse_string(string))
print(reverse(string))

"""
sitruk
sitruk
"""

#4 Complesso è meglio che complicato 

Ora, lavare i piatti con un'idropulitrice è poco pratico: faresti meglio con una soluzione semplice come l'acqua corrente del rubinetto. Ma se il problema fosse pulire un 4x4 Range Rover? Il precedente aforisma e questo ci ricordano che sia tecniche semplici sia tecniche complesse possono essere applicate per risolvere un problema. Pulire un 4x4 Range Rover non è un problema semplice e provare ad applicare le stesse tecniche che useresti per lavare i piatti può anche funzionare, ma è più complicato che usare un'idropulitrice. Quindi, dovresti preferire la semplicità alla complessità, ma nelle situazioni in cui la semplicità è impraticabile, è meglio optare per la complessità: conosci i limiti della semplicità. 

#5 Piatto è meglio che annidato 

I programmatori amano organizzare le cose in categorie, sottocategorie e sotto-sottocategorie per separare le funzionalità. Anche se può sembrare ordinato, organizzare il codice in questo modo può portare a più confusione che ordine. 

Non c'è nulla di male nel mettere tutto il tuo codice in un modulo di primo livello: significa che non dovresti fare qualcosa come from spam.foo.bar.john.doe import chicken per accedere a una specifica funzionalità. Più sottocategorie aggiungi, più il tuo codice diventa complicato. Fai il possibile per mantenere una struttura piatta quando è possibile.

#6 Rado è meglio che denso

I programmatori sono considerati tra gli esseri umani più intelligenti, quindi non c'è bisogno di sottolineare il tuo intelletto con trovate eccessivamente elaborate. La più comune che sentirai è "come fare [qualche compito complicato] in una riga di codice". A volte i one-liner sono giustificati, ma evita le situazioni in cui sacrifichi la leggibilità solo per far entrare tutta la funzionalità in una riga. 

Prendi questo pezzo di codice come esempio: 

"""
Code source Al Sweigart
See: https://inventwithpython.com/blog/author/al-sweigart.html0
"""
print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))
"""
1 bytes = 8 bits which has 255 possible values.
2 bytes = 16 bits which has 65535 possible values.
4 bytes = 32 bits which has 4294967295 possible values.
8 bytes = 64 bits which has 18446744073709551615 possible values.
16 bytes = 128 bits which has 340282366920938463463374607431768211455 possible values.
32 bytes = 256 bits which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values.
64 bytes = 512 bits which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values.
128 bytes = 1024 bits which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values.
"""

Il codice sicuramente funziona ma è un vero incubo da capire: è compresso e difficile da leggere. 

Vediamo come apparirebbe lo stesso codice se lo scrivessimo in modo più rado: 

# Sparse example
bytes_and_bits = {j: j*8 for j in (1 << i for i in range(8))}

for bytes, bits in bytes_and_bits.items():
    print(f"{bytes} bytes = {bits} which has {256**bytes-1} possible values")

"""
1 bytes = 8 which has 255 possible values
2 bytes = 16 which has 65535 possible values
4 bytes = 32 which has 4294967295 possible values
8 bytes = 64 which has 18446744073709551615 possible values
16 bytes = 128 which has 340282366920938463463374607431768211455 possible values
32 bytes = 256 which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values
64 bytes = 512 which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values
128 bytes = 1024 which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values
"""

Il codice qui sopra è molto più leggibile e fa esattamente la stessa cosa del one-liner.

#7 La leggibilità conta

Se non l'avessi già intuito, in Python la leggibilità conta. Il tuo lavoro è scrivere il codice una volta sola. Tuttavia, è molto probabile che venga letto più e più volte. Tenendo conto di ciò, togliere le vocali dai nomi di variabili e funzioni non è una buona idea: se puoi chiamare una funzione create_lst o create_list, scegli la seconda. 

#8 I casi speciali non sono abbastanza speciali da infrangere le regole

Python [e la programmazione in generale] è pieno di buone pratiche da seguire. È meglio attenersi alle best practice che fare a modo tuo, perché spesso questo porta a codice incoerente e poco leggibile. 

#9 Anche se la praticità batte la purezza

La lezione nove è un'estensione della lezione otto. Sì, è meglio seguire le best practice, ma sforzarsi troppo per aderire alle regole può anche produrre codice poco leggibile. Dunque, ogni regola può avere un'eccezione. Se il tuo modo di risolvere un problema è più pratico, leggibile e facile da capire, allora è meglio deviare dalle best practice consolidate. 

#10 Gli errori non dovrebbero mai passare sotto silenzio 

Un errore silenzioso si verifica quando un programma restituisce un codice di errore o None invece di sollevare un'eccezione. È meglio che un programma vada in crash piuttosto che l'errore venga messo a tacere e l'esecuzione prosegua. A lungo termine, zittire gli errori può portare a bug nel tuo programma molto più difficili da eliminare. 

#11 A meno che non siano messi a tacere in modo esplicito

L'undicesima lezione è un'estensione della decima. Ci sono casi in cui potresti voler ignorare errori causati dal tuo programma. In tali casi, la buona pratica è mettere esplicitamente a tacere l'errore nel tuo codice. 

#12 Di fronte all'ambiguità, rifiuta la tentazione di indovinare

I computer fanno solo ciò che diciamo loro di fare: se il tuo codice non si comporta come vorresti, è perché sta facendo ciò che gli hai detto di fare. Cercare di correggere il comportamento provando alla cieca varie soluzioni finché una non funziona è una pessima strategia: potresti finire per mascherare il problema invece di risolverlo. Resisti alla tentazione. Invece, ragiona sulla logica del problema e applica il pensiero critico per arrivare a una soluzione adeguata. 

#13 Dovrebbe esserci un modo - e preferibilmente uno soltanto - ovvio per farlo 

Il motto del linguaggio Perl è: "C'è più di un modo per farlo!" Avere troppe opzioni porta spesso al sovraccarico di scelta. Si verifica uno scenario simile quando ci sono diversi modi di scrivere codice che raggiunge lo stesso obiettivo. Hai più flessibilità nel modo in cui scrivi il codice, ma ora per leggerlo devi conoscere tutti i modi possibili in cui avrebbe potuto essere scritto: il lavoro extra richiesto per apprendere tutti gli scenari è inutile. 

#14 Anche se quel modo potrebbe non essere ovvio all'inizio a meno che tu non sia olandese

Questo aforisma mostra il senso dell'umorismo di Tim Peters: Guido van Rossum, creatore del linguaggio Python e Benevolent Dictator For Life (BDFL) per Python, è olandese. È una battuta che ci ricorda che comprendere e ricordare le regole del linguaggio Python è difficile per tutti tranne che per il suo creatore. 

#15 Adesso è meglio che mai

Questo aforisma ci dice che un codice bloccato in un ciclo infinito o che si impianta è peggiore di un codice che non lo fa. 

#16 Anche se mai è spesso meglio di proprio adesso

Proseguendo dalla lezione sedici: è meglio aspettare che il tuo programma finisca l'esecuzione piuttosto che terminarlo in anticipo e ottenere risultati errati. 

#17 Se l'implementazione è difficile da spiegare, è una cattiva idea

Non basta che tu capisca le tue implementazioni - "so cosa sto cercando di dire" non è sufficiente. La programmazione è un'attività di squadra e, se non riesci a spiegare la tua implementazione ai compagni, è molto probabile che tu abbia reso la soluzione troppo complicata. 

#18 Se l'implementazione è facile da spiegare, potrebbe essere una buona idea

Tuttavia, un codice facile da spiegare non significa necessariamente che non sia cattivo codice - significa solo che è facile da spiegare. Potresti comunque avere cattivo codice, ma il fatto che sia facile da spiegare indica che sei sulla strada giusta. 

#19 Gli spazi dei nomi sono un'idea straordinaria - facciamone di più!

Uno spazio dei nomi è un'astrazione usata in Python per organizzare i nomi assegnati agli oggetti in un programma. Quando è presentato uno specifico namespace e scope, Python è in grado di determinare a quale oggetto ti riferisci quando richiami un nome simbolico. Tutto ciò che questo aforisma dice è che il modo in cui Python organizza i nomi simbolici sotto il cofano è davvero fantastico. 

Conclusione 

In questo articolo, abbiamo presentato la nostra interpretazione dello Zen di Python, linee guida pensate per motivare i programmatori Python a scrivere codice pulito e leggibile. Mentre alcuni considerano lo Zen di Python il modello definitivo per una scrittura del codice senza intoppi, altri lo prendono meno sul serio.  Ti suggeriamo di provare ad applicare i principi al tuo codice per vedere in prima persona come possano migliorare il tuo lavoro.  Se vuoi approfondire come scrivere codice ottimizzato, dai un'occhiata a Writing Efficient Python Code di DataCamp.