Per la programmazione Python e l'essere Pythonic, perché "non è mai spesso meglio di * right * now"? [chiuso]

8

Nello Zen di Python, posso comprenderne la maggior parte, eccetto:

Now is better than never.  
Although never is often better than *right* now

Quindi penso che farlo ora o ottenere risultati ora sia meglio che mai. Ma perché "non è mai spesso meglio di * giusto * ora"? O cosa significa?

Per vedere le 2 linee precedenti nel contesto, questo è l'intero Zen di Python:

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!
    
posta 太極者無極而生 13.02.2016 - 07:12
fonte

4 risposte

12

La prima parte, "ora è meglio che mai", è un mantra contro la procrastinazione. Esprime l'idea che, se non riesci ad andare avanti, non riuscirai mai a risolverlo.

La seconda parte, "mai è spesso meglio di adesso , è un'espressione di YAGNI principio: dovresti "implementare sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno", perché spesso scopri che non ne hai più bisogno, e poi scopri che hai appena perso uno sforzo.

... beh, questa è la mia comprensione. Ma dovresti chiedere all'autore per essere sicuro.

    
risposta data 13.02.2016 - 07:55
fonte
2

Potrebbe essere una valutazione pigra.

Esempi:

xrange(1000000)

vs

range(1000000) 

Dove il primo non fa molto fino a quando i valori sono necessari, ma quest'ultimo alloca un grande array.

O registrazione

log("Stuff happened for %s ",  something)

vs

log("Stuff happened for %s " % something)

Dove il primo non crea la stringa a meno che il logging non sia effettivamente abilitato.

    
risposta data 13.02.2016 - 07:26
fonte
1

Penso che questi si applichino al processo di progettazione della lingua stessa, non solo alle applicazioni. "Ora è meglio che mai." e "Sebbene non sia mai spesso meglio di right ora." si tratta di trovare il giusto equilibrio per tempo e qualità di implementazione. È lo stesso con il resto dello Zen. E, naturalmente, lo Zen non ha un solo significato, in base alla progettazione.

    
risposta data 14.02.2016 - 19:41
fonte
1

Now is better than never.
Although never is often better than right now

Penso che la prima riga si riferisca a un mix di perfezionismo e procrastinazione. È meglio fornire qualcosa che funzioni, anche se la funzionalità è di base o il codice "non ancora perfetto", piuttosto che lavorarci su per sempre finché non si esaurisce il codice e il codice finisce morto.

Per quanto riguarda la seconda linea, penso che sia rivolta a implementazioni affrettate. Di solito, le cose che codificate hanno un impatto molto duraturo una volta rilasciate. A volte, si potrebbe essere tentati di spedire rapidamente qualcosa, soprattutto fuori dalla pressione, che si trasformerà in un peso per gli anni successivi. Si chiama "debito tecnico": le cattive decisioni di progettazione, le cattive interfacce o solo i poveri costrutti portano a molti problemi lungo la strada. Il codice è raramente solo, un sacco di altro codice si basa rapidamente su di esso, e se hai preso una decisione sbagliata, sei bloccato con esso. Pertanto, non affrettare le versioni, assicurati che siano utili.

    
risposta data 15.02.2016 - 18:15
fonte

Leggi altre domande sui tag