Perché i metodi "privati" di Python non sono in realtà privati?

Python ci dà la possibilità di creare metodi di 'privato' e le variabili all'interno di una classe anteponendo doppia sottolineatura per il nome, in questo modo: __myPrivateMethod(). Come, quindi, si può spiegare questo

>>> class MyClass:
...     def myPublicMethod(self):
...             print 'public method'
...     def __myPrivateMethod(self):
...             print 'this is private!!'
... 
>>> obj = MyClass()
>>> obj.myPublicMethod()
public method
>>> obj.__myPrivateMethod()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: MyClass instance has no attribute '__myPrivateMethod'
>>> dir(obj)
['_MyClass__myPrivateMethod', '__doc__', '__module__', 'myPublicMethod']
>>> obj._MyClass__myPrivateMethod()
this is private!!

Qual è l'accordo?!

Lo spiegherò un po 'per coloro che non l'hanno capito.

>>> class MyClass:
...     def myPublicMethod(self):
...             print 'public method'
...     def __myPrivateMethod(self):
...             print 'this is private!!'
... 
>>> obj = MyClass()

Quello che ho fatto lì è creare una classe con un metodo pubblico e un metodo privato e istanziarlo.

Successivamente, chiamo il suo metodo pubblico.

>>> obj.myPublicMethod()
public method

Successivamente, provo a chiamare il suo metodo privato.

>>> obj.__myPrivateMethod()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: MyClass instance has no attribute '__myPrivateMethod'

Qui tutto sembra a posto; non siamo in grado di chiamarlo. È, infatti, "privato". Bene, in realtà non lo è. L'esecuzione di dir () sull'oggetto rivela un nuovo metodo magico che Python crea magicamente per tutti i tuoi metodi "privati".

>>> dir(obj)
['_MyClass__myPrivateMethod', '__doc__', '__module__', 'myPublicMethod']

Il nome di questo nuovo metodo è sempre un carattere di sottolineatura, seguito dal nome della classe, seguito dal nome del metodo.

>>> obj._MyClass__myPrivateMethod()
this is private!!

Tanto per l'incapsulamento, eh?

In ogni caso, ho sempre sentito che Python non supporta l'incapsulamento, quindi perché provarci? Cosa dà?

Il nome scrambling viene utilizzato per garantire che le sottoclassi non sovrascrivano accidentalmente i metodi e gli attributi privati ​​delle loro superclassi. Non è progettato per impedire l'accesso deliberato dall'esterno.

Per esempio:

>>> class Foo(object):
...     def __init__(self):
...         self.__baz = 42
...     def foo(self):
...         print self.__baz
...     
>>> class Bar(Foo):
...     def __init__(self):
...         super(Bar, self).__init__()
...         self.__baz = 21
...     def bar(self):
...         print self.__baz
...
>>> x = Bar()
>>> x.foo()
42
>>> x.bar()
21
>>> print x.__dict__
{'_Bar__baz': 21, '_Foo__baz': 42}

Naturalmente, si rompe se due classi diverse hanno lo stesso nome.

Esempio di funzione privata

import re
import inspect

class MyClass :

    def __init__(self) :
        pass

    def private_function ( self ) :
        try :
            function_call = inspect.stack()[1][4][0].strip()

            # See if the function_call has "self." in the begining
            matched = re.match( '^self\.', function_call )
            if not matched :
                print 'This is Private Function, Go Away'
                return
        except :
            print 'This is Private Function, Go Away'
            return

        # This is the real Function, only accessible inside class #
        print 'Hey, Welcome in to function'

    def public_function ( self ) :
        # i can call private function from inside the class
        self.private_function()

### End ###

Quando sono arrivato per la prima volta da Java a Python, odiavo questo. Mi ha spaventato a morte.

Oggi potrebbe essere l'unica cosa che amo di più di Python.

Adoro stare su una piattaforma, dove le persone si fidano l'una dell'altra e non si sentono come se dovessero costruire muri impenetrabili attorno al loro codice. In linguaggi fortemente incapsulati, se un'API ha un bug e hai capito cosa non va, potresti non essere ancora in grado di aggirare il problema perché il metodo necessario è privato. In Python l'atteggiamento è: "sicuro". Se pensi di capire la situazione, forse l'hai persino letta, allora tutto ciò che possiamo dire è "buona fortuna!".

Ricorda, l'incapsulamento non è nemmeno debolmente correlato alla "sicurezza", o alla custodia dei bambini dal prato. È solo un altro modello che dovrebbe essere usato per rendere più semplice la comprensione di una base di codice.

Da http://www.faqs.org/docs/diveintopython/fileinfo_private.html

A rigor di termini, i metodi privati ​​sono accessibili al di fuori della loro classe, semplicemente non facilmente accessibili. Niente in Python è veramente privato; internamente, i nomi di metodi e attributi privati ​​sono alterati e non frastagliati al volo per farli sembrare inaccessibili con i loro nomi. Puoi accedere al metodo __parse della classe MP3FileInfo con il nome _MP3FileInfo__parse. Riconosci che questo è interessante, quindi prometti di non farlo mai, mai nel vero codice. I metodi privati ​​sono privati ​​per una ragione, ma come molte altre cose in Python, la loro riservatezza è in definitiva una questione di convenzione, non di forza.

La frase comunemente usata è "siamo tutti adulti consenzienti qui". Anticipando un singolo carattere di sottolineatura (non esporre) o doppio carattere di sottolineatura (nascondi), stai dicendo all'utente della tua classe che in qualche modo intendi che il membro sia "privato". Tuttavia, ti fidi di tutti gli altri di comportarsi in modo responsabile e di rispettarlo, a meno che non abbiano un motivo convincente di non farlo (ad esempio debugger, completamento del codice).

Se devi davvero avere qualcosa di privato, puoi implementarlo in un'estensione (ad es. In C per CPython). Nella maggior parte dei casi, tuttavia, impari semplicemente il modo pitone di fare le cose.

Non è che tu non riesca assolutamente a evitare la riservatezza dei membri in nessun linguaggio (aritmetica del puntatore in C ++, Reflections in .NET / Java).

Il punto è che viene visualizzato un errore se si tenta di chiamare il metodo privato per errore. Ma se vuoi spararti al piede, vai avanti e fallo.

Modifica: non provi a proteggere le tue cose con l'incapsulamento OO, vero?

La class.__stuffconvenzione di denominazione fa sapere al programmatore che non è destinato ad accedere __stuffdall'esterno. Il nome mangling rende improbabile che qualcuno lo faccia per caso.

È vero, puoi ancora aggirare questo, è ancora più facile che in altre lingue (che BTW ti consente anche di fare questo), ma nessun programmatore Python lo farebbe se si preoccupasse dell'incapsulamento.

Un comportamento simile esiste quando i nomi degli attributi del modulo iniziano con un singolo trattino basso (ad es. _Foo).

Gli attributi del modulo nominati come tali non verranno copiati in un modulo di importazione quando si utilizza il from*metodo, ad esempio:

from bar import *

Tuttavia, questa è una convenzione e non un vincolo linguistico. Questi non sono attributi privati; possono essere referenziati e manipolati da qualsiasi importatore. Alcuni sostengono che per questo motivo, Python non può implementare l'incapsulamento reale.

È solo una di quelle scelte di design del linguaggio. Ad un certo livello sono giustificati. Lo fanno quindi devi andare abbastanza lontano dal tuo modo di provare a chiamare il metodo e se ne hai davvero bisogno, devi avere una ragione abbastanza buona!

Hook di debug e test vengono in mente come possibili applicazioni, utilizzate in modo responsabile ovviamente.

Con Python 3.4 questo è il comportamento:

>>> class Foo:
        def __init__(self):
                pass
        def __privateMethod(self):
                return 3
        def invoke(self):
                return self.__privateMethod()


>>> help(Foo)
Help on class Foo in module __main__:

class Foo(builtins.object)
 |  Methods defined here:
 |
 |  __init__(self)
 |
 |  invoke(self)
 |
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |
 |  __dict__
 |      dictionary for instance variables (if defined)
 |
 |  __weakref__
 |      list of weak references to the object (if defined)

 >>> f = Foo()
 >>> f.invoke()
 3
 >>> f.__privateMethod()
 Traceback (most recent call last):
   File "<pyshell#47>", line 1, in <module>
     f.__privateMethod()
 AttributeError: 'Foo' object has no attribute '__privateMethod'

https://docs.python.org/3/tutorial/classes.html#tut-private

Si noti che le regole di demolizione sono progettate principalmente per evitare incidenti; è ancora possibile accedere o modificare una variabile considerata privata. Questo può essere utile anche in circostanze speciali, come nel debugger.

Anche se la domanda è vecchia, spero che il mio frammento possa essere utile.

La preoccupazione più importante per i metodi e gli attributi privati ​​è di dire agli sviluppatori di non chiamarlo al di fuori della classe e questo è l'incapsulamento. si può fraintendere la sicurezza dall'incapsulamento. quando uno usa deliberatamente la sintassi come quella (qui sotto) che hai menzionato, non vuoi incapsulare.

obj._MyClass__myPrivateMethod()

Sono migrato da C # e all'inizio è stato strano anche per me, ma dopo un po 'sono arrivato all'idea che solo il modo in cui i progettisti di codice Python pensano a OOP è diverso.

Perché i metodi "privati" di Python non sono in realtà privati?

A quanto ho capito, non possono essere privati. Come si può far rispettare la privacy?

La risposta ovvia è che "i membri privati ​​sono accessibili solo attraverso self", ma che non funzionerebbe - selfnon è speciale in Python, non è altro che un nome comunemente usato per il primo parametro di una funzione.