Dlaczego „prywatne” metody Pythona nie są prywatne?

Python daje nam możliwość tworzenia „prywatny” metod i zmiennych w klasie przez poprzedzenie podwójne podkreślenia do nazwy, na przykład: __myPrivateMethod(). Jak zatem to wyjaśnić

>>> 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!!

O co chodzi?!

Wytłumaczę to trochę tym, którzy tego nie rozumieją.

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

To, co tam zrobiłem, to utworzenie klasy za pomocą metody publicznej i prywatnej oraz utworzenie jej instancji.

Następnie nazywam tę metodę publiczną.

>>> obj.myPublicMethod()
public method

Następnie próbuję wywołać jego prywatną metodę.

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

Tutaj wszystko wygląda dobrze; nie możemy tego nazwać. W rzeczywistości jest „prywatny”. Właściwie to nie jest. Uruchomienie dir () na obiekcie ujawnia nową magiczną metodę, którą Python tworzy magicznie dla wszystkich twoich „prywatnych” metod.

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

Nazwa tej nowej metody jest zawsze znakiem podkreślenia, po której następuje nazwa klasy, a następnie nazwa metody.

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

Tyle o enkapsulacji, co?

W każdym razie zawsze słyszałem, że Python nie obsługuje enkapsulacji, więc po co w ogóle próbować? Co daje?

Szyfrowanie nazw służy do tego, aby podklasy przypadkowo nie zastępowały prywatnych metod i atrybutów ich nadklas. Nie jest zaprojektowany, aby zapobiegać celowemu dostępowi z zewnątrz.

Na przykład:

>>> 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}

Oczywiście psuje się, jeśli dwie różne klasy mają tę samą nazwę.

Przykład funkcji prywatnej

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 ###

Kiedy po raz pierwszy przyszedłem z Javy do Pythona, nienawidziłem tego. Przestraszyło mnie to na śmierć.

Dzisiaj może to być jedna rzecz, którą najbardziej lubię w Pythonie.

Uwielbiam być na platformie, na której ludzie sobie ufają i nie czują, że muszą budować nieprzeniknione ściany wokół swojego kodu. W silnie zamkniętych językach, jeśli interfejs API zawiera błąd, a ty zorientowałeś się, co poszło nie tak, nadal możesz nie być w stanie go obejść, ponieważ potrzebna metoda jest prywatna. W Pythonie postawa brzmi: „pewnie”. Jeśli uważasz, że rozumiesz sytuację, być może nawet ją przeczytałeś, to wszystko, co możemy powiedzieć, to „powodzenia!”.

Pamiętaj, że kapsułkowanie nie jest nawet słabo związane z „bezpieczeństwem” lub utrzymywaniem dzieci z dala od trawnika. To tylko kolejny wzorzec, który powinien być użyty, aby podstawa kodu była łatwiejsza do zrozumienia.

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

Ściśle mówiąc, prywatne metody są dostępne poza ich klasą, po prostu nie są łatwo dostępne. Nic w Pythonie nie jest naprawdę prywatne; wewnętrznie nazwy prywatnych metod i atrybutów są zniekształcone i rozszyfrowane w locie, aby wydawały się niedostępne pod ich nazwami. Możesz uzyskać dostęp do metody __parse klasy MP3FileInfo pod nazwą _MP3FileInfo__parse. Uznaj, że jest to interesujące, a następnie obiecaj, że nigdy, nigdy nie zrobisz tego w prawdziwym kodzie. Prywatne metody są prywatne z jakiegoś powodu, ale podobnie jak wiele innych rzeczy w Pythonie, ich prywatność jest ostatecznie kwestią konwencji, a nie siły.

Często używanym zwrotem jest „wszyscy tutaj zgadzamy się na dorosłych”. Przygotowując pojedynczy znak podkreślenia (nie ujawniaj) lub podwójny znak podkreślenia (ukryj), mówisz użytkownikowi swojej klasy, że zamierzasz być w jakiś sposób „prywatny”. Jednak ufasz wszystkim, którzy zachowują się odpowiedzialnie i szanują to, chyba że mają ku temu ważny powód (np. Debuggery, uzupełnianie kodu).

Jeśli naprawdę musisz mieć coś prywatnego, możesz to zaimplementować w rozszerzeniu (np. W C dla CPython). Jednak w większości przypadków po prostu uczysz się Pythońskiego sposobu robienia rzeczy.

To nie tak, że absolutnie nie możesz ominąć prywatności członków w żadnym języku (arytmetyka wskaźników w C ++, Refleksje w .NET / Java).

Chodzi o to, że pojawia się błąd, jeśli przypadkowo wywołujesz metodę prywatną. Ale jeśli chcesz strzelić sobie w stopę, zrób to.

Edycja: Nie próbujesz zabezpieczyć swoich rzeczy za pomocą enkapsulacji OO, prawda?

The class.__stuffKonwencja nazewnictwa pozwala programista wie, że nie ma dostępu __stuffz zewnątrz. Nazwa „mangling” sprawia, że ​​jest mało prawdopodobne, że ktoś zrobi to przypadkowo.

To prawda, że ​​nadal możesz to obejść, jest to nawet łatwiejsze niż w innych językach (które BTW również pozwala ci to zrobić), ale żaden programista Python nie zrobiłby tego, jeśli zależy mu na enkapsulacji.

Podobne zachowanie występuje, gdy nazwy atrybutów modułów zaczynają się od pojedynczego podkreślenia (np. _Foo).

Atrybuty modułu nazwane jako takie nie zostaną skopiowane do modułu importującego podczas korzystania z from*metody, np .:

from bar import *

Jest to jednak konwencja, a nie ograniczenie językowe. To nie są prywatne atrybuty; mogą być przywoływane i manipulowane przez dowolnego importera. Niektórzy twierdzą, że z tego powodu Python nie może zaimplementować prawdziwej enkapsulacji.

To tylko jedna z opcji wyboru języka. Na pewnym poziomie są uzasadnione. Robią to, więc musisz zrobić wszystko, co w twojej mocy, aby wywołać metodę, a jeśli naprawdę potrzebujesz jej tak bardzo, musisz mieć całkiem dobry powód!

Debugowanie haków i testowanie przychodzą na myśl jako możliwe aplikacje, oczywiście używane w sposób odpowiedzialny.

W Pythonie 3.4 jest to zachowanie:

>>> 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

Należy pamiętać, że reguły zniekształcania mają na celu przede wszystkim uniknięcie wypadków; nadal można uzyskać dostęp lub zmodyfikować zmienną uważaną za prywatną. Może to być przydatne nawet w szczególnych okolicznościach, takich jak debugger.

Nawet jeśli pytanie jest stare, mam nadzieję, że mój fragment może być pomocny.

Najważniejszą kwestią związaną z prywatnymi metodami i atrybutami jest poinformowanie programistów, aby nie nazywali go poza klasą, a to jest hermetyzacja. można źle zrozumieć bezpieczeństwo wynikające z hermetyzacji. kiedy ktoś celowo używa takiej składni (poniżej), o której wspomniałeś, nie chcesz enkapsulacji.

obj._MyClass__myPrivateMethod()

Przeprowadziłem migrację z C # i na początku też było to dla mnie dziwne, ale po pewnym czasie doszedłem do wniosku, że tylko sposób, w jaki projektanci kodu Python myślą o OOP, jest inny.

Dlaczego „prywatne” metody Pythona nie są prywatne?

Jak rozumiem, nie mogą być prywatni. Jak można egzekwować prywatność?

Oczywista odpowiedź brzmi: „członkowie prywatni są dostępni tylko przez self”, ale to nie zadziałałoby - selfnie jest to szczególne w Pythonie, jest niczym więcej niż powszechnie używaną nazwą pierwszego parametru funkcji.