Perché non ci sono modificatori di accesso espliciti in Python:

Question

Perché non ci sono modificatori di accesso espliciti in Python:

#1 da (19 voti)
#2 da (9 voti)
#3 da (7 voti)

26

Se "esplicito è meglio di implicito", perché non esistono modificatori di accesso espliciti in Python: pubblico, protetto, privato, ecc.?

So che l'idea è che il programmatore sappia cosa fare attraverso un suggerimento: non è necessario usare la "forza bruta". Ma IMO "incapsulamento" o "occultamento dell'informazione" non è solo per tenere fuori le persone, è una questione di organizzazione e struttura: i livelli di sviluppo dovrebbero avere confini e confini auto-definiti, chiaramente delimitati, proprio come fanno i sistemi fisici.

Qualcuno, per favore, può darmi una mano qui con una spiegazione esauriente del motivo per cui le restrizioni di accesso sono implicite piuttosto che esplicite in Python, un linguaggio che altrimenti sembra vicino alla perfezione?

Modifica: finora ho visto 3 risposte proposte e mi sono reso conto che ci sono 2 parti nella mia domanda:

Perché non ci sono parole chiave, ad esempio
```
private def myFunc(): 
    dostuff....
```
invece di IMO i caratteri di sottolineatura brutti e difficili da digitare. Ma non è questo il punto importante.
Ancora più importante:

Perché questi modificatori di accesso sono solo "consigli" o suggerimenti e non applicati. Sarà difficile cambiare dopo? È molto semplice cambiare 'protected' in 'public' - e se hai una catena di eredità complicata che rende difficile, hai un design scarso - il tuo design dovrebbe essere raffinato piuttosto che fare affidamento su una funzione linguistica che rende facile scrivere codice mal strutturato.

Quando i modificatori di accesso vengono applicati, il tuo codice viene automaticamente suddiviso in compartimenti: sai che alcuni segmenti sono fuori portata, quindi non devi gestirli se non quando è necessario. E, se il tuo design non è buono e ti ritrovi a spostare costantemente le cose dentro e fuori dai diversi ambiti, la lingua può aiutarti a ripulire il tuo operato.

Per quanto ami Python, trovo che questo secondo punto sia una grave carenza. E devo ancora vedere una buona risposta per questo.

access-modifiers python

posta Vector 11.07.2011 - 08:24

fonte

3 risposte

9

Sospetto che il motivo principale per i modificatori di accesso mancanti sia Simplicity

Come dici tu, non si tratta di tenere le persone fuori, è sull'organizzazione, quindi il punto principale di "privato" è che invia un messaggio agli utenti della tua API "per favore non scrivere il codice che dipende da questo".

È banale dire "per convenzione, _x o __x non dovrebbero essere usati al di fuori della classe", ma nel modello di oggetti dinamici di Python, sarebbe difficile persino creare una notazione.

class ActiveRow(object):
    def __init__(self, **kwargs):
        for name, value in kwargs.items():
            setattr(self, name, value)

come prendere nota dell'accessibilità?

Immagino, questo è stato un compromesso. Se non riesci a conviverci strettamente, ti suggerirei ruby, che ha un simile livello di astrazione e dinamicità, ma ha un modello a oggetti, che consente la modifica dell'accesso.

risposta data 11.07.2011 - 08:38

fonte

7

La convenzione Python utilizza un prefisso di sottolineatura per i membri protetti / privati.

Questa convenzione, quando seguita, è effettivamente uguale ai modificatori di accesso, tranne 1) vedrai direttamente dal nome del membro, sia che sia pubblico o meno, e 2) tu possibile interrompe "l'incapsulamento" se lo vuoi veramente (questo può essere giustificato ad esempio nel test, in alcuni altri linguaggi dovresti usare reflection == altro codice).

In definitiva è una questione di gusti, ma se puoi fare la stessa cosa (con un po 'più di flessibilità) senza parole chiave speciali, la lingua sarà più piccola e il codice sarà più conciso, che generalmente è una buona cosa.

risposta data 11.07.2011 - 08:33

fonte

Leggi altre domande sui tag access-modifiers python

È compito di uno sviluppatore suggerire i requisiti IT? Sviluppare il mio slancio su progetti open source [duplicato]

score 19 · Accepted Answer

"Explicit is better than implicit" è solo una delle massime nella filosofia di design di Python. "Semplice è meglio che complesso" c'è anche lì. E, anche se non è nello Zen di Python, "Siamo tutti adulti consenzienti qui" è un altro.

Questa seconda regola è forse la più importante qui. Quando progetto una classe, ho un'idea di come verrà utilizzata. Ma non posso assolutamente prevedere tutti i possibili usi. potrebbe essere che un uso futuro del mio codice richiede l'accesso alle variabili che ho pensato come private. Perché dovrei rendere difficile - o addirittura impossibile - accedervi, se un futuro programmatore (o anche un futuro me) ne ha bisogno? La cosa migliore da fare è contrassegnarli con un avvertimento - come nota Joonas, un singolo prefisso di sottolineatura è lo standard - che sono interni e potrebbero cambiare; ma proibire l'accesso sembra del tutto superfluo.