Perché gli sviluppatori Python trasmettono stringhe speciali alle funzioni anziché simboli definiti? [chiuso]

Question

Perché gli sviluppatori Python trasmettono stringhe speciali alle funzioni anziché simboli definiti? [chiuso]

#1 da (3 voti)
#2 da (2 voti)

0

C'è una ragione per cui gli sviluppatori Python (entrambi manutentori di Python stesso e autori di moduli) tendono a passare stringhe speciali come argomenti per le funzioni invece di definire simboli per lo stesso scopo? Piuttosto che far cercare ad altri sviluppatori o indovinare i valori speciali consentiti per alcuni argomenti, perché non definire i simboli per rappresentarli?

L'esempio più semplice di ciò a cui posso pensare in base Python è open() funzione. Per specificare la modalità in cui viene aperto un file, l'argomento mode può assumere uno dei vari valori stringa. Ad esempio, per aprire un file per la scrittura:

fileObject = open('/tmp/tarfu.txt', 'w')

Perché non definire i simboli per rappresentare i valori consentiti per mode ? Cioè costanti, enumerazioni, membri della classe o qualcosa di simile.

Una semplice definizione potrebbe essere aggiunta allo stesso modulo che definisce open() ( io , credo):

OPEN_MODE_WRITE = 'w'

Quindi potrebbe essere utilizzato con open() :

fileObject = open('/tmp/tarfu.txt', OPEN_MODE_WRITE)

Sarebbe simile ad altri linguaggi, come PHP, Java, C e altri. Sebbene le funzioni di apertura di file corrispondenti di quelle altre lingue potrebbero non essere esempi dell'ideale, quelle lingue hanno più esempi di essa rispetto a Python. Tutti comunemente definiscono simboli per tali scopi. Usarli aiuta a ottenere il giusto valore, specialmente se l'editor dello sviluppatore ha funzionalità per completare automaticamente o suggerire simboli. Se i simboli sono di un tipo specifico (come nelle enumerazioni o nei membri della classe), anche i tipi degli argomenti possono essere controllati.

Usando le stringhe per questi valori speciali, gli errori nel codice possono essere rilevati solo in fase di esecuzione, il che potrebbe essere difficile da rintracciare nel codice all'origine del problema. Usare i simboli renderebbe anche il codice più facile da capire, il che credo lo renderebbe più Pythonic .

Tutto ciò che ho scritto qui in riferimento alle stringhe si applica anche ai numeri. Sono stato ispirato a scrivere questa domanda dopo aver usato i panda per un po '. Diverse funzioni consentono allo sviluppatore di specificare se un'operazione si applica a righe o colonne di un oggetto DataFrame fornendo i numeri 0 e 1 o le stringhe rows e columns per l'argomento axis . Preferirei avere simboli come AXIS_ROWS e AXIS_COLUMNS definiti per questo scopo.

coding-style python

posta L S 19.07.2018 - 17:48

fonte

2 risposte

Leggi altre domande sui tag coding-style python

È Branching l'opzione migliore al posto del biforcarsi per i repository git Come dovrei strutturare un test automatizzato con una dipendenza su un endpoint HTTP?

score 3 · Answer 1

Questo codice Python:

fileObject = open('/tmp/tarfu.txt', 'w')

è quasi identico a questa chiamata di funzione C:

file = fopen('/tmp/tarfu.txt', 'w');

Quindi apparentemente l'hanno fatto in questo modo per ragioni storiche.

L'interruttore di modalità è un singolo carattere. È piuttosto difficile rovinare tutto, ed è completamente documentato nella letteratura di Python.

Vedi anche
funzione libreria C - fopen ()

score 2 · Answer 2

In linguaggi tipizzati staticamente come C ++ puoi usare enum per creare un tipo che è limitato a un intervallo di valori. Ad esempio,

enum OpenMode {READ_ONLY, READ_WRITE};

crea un tipo che può essere usato come argomento per una funzione open :

open(string filename, OpenMode mode);

Così facendo non solo si migliora la leggibilità: ora è impossibile passare qualcosa di diverso da un oggetto OpenMode a open . Ad esempio, chiamando open("file.txt", "w") si genera un errore del compilatore .

Qualcosa come questo non può essere fatto in Python, che è digitato in modo dinamico o anatra. Non ci sono enumerazioni (almeno prima della versione 3.4) e non c'è compilatore. L'aggiunta di una costante OPEN_MODE_READ_ONLY "solo" migliora la leggibilità. Tuttavia, dopo aver aggiunto una costante di questo tipo, ci sono due modi per chiamare open . Ora puoi usare

open("file.txt", OPEN_MODE_READ_ONLY)

ma alla vecchia maniera

open("file.txt", "w")

è ancora valido, perché OPEN_MODE_READ_ONLY e "w" hanno lo stesso valore. Si può ora sostenere che questo non è tutto pirotecnico, perché Ci dovrebbe essere uno - e preferibilmente solo un modo - ovvio per farlo.

Fortunatamente, il linguaggio e la comunità Python abbracciano cambiamenti utili e non li abbandona solo perché "lo abbiamo sempre fatto in questo modo". Python 3.4 ha introdotto il modulo enum e forse l'abitudine agli argomenti delle stringhe magiche scompare non appena il modulo enum viene stabilito e accettato dalla maggioranza delle persone.