Quando si definisce un metodo su una classe in Python, è simile al seguente:

class MyClass(object):
    def __init__(self, x, y):
        self.x = x
        self.y = y

Ma in alcuni altri linguaggi, come C #, hai un riferimento all'oggetto a cui il metodo è associato con la parola chiave "this" senza dichiararlo come argomento nel prototipo del metodo.

È stata una decisione intenzionale di progettazione del linguaggio in Python o ci sono alcuni dettagli di implementazione che richiedono il passaggio di "sé" come argomento?

Mi piace citare lo Zen di Python di Peters. "Esplicito è meglio che implicito."

In Java e C ++, ' this.' può essere dedotto, tranne quando si hanno nomi di variabili che lo rendono impossibile da dedurre. Quindi a volte ne hai bisogno ea volte no.

Python sceglie di rendere esplicite cose del genere piuttosto che basate su una regola.

Inoltre, poiché nulla è implicito o assunto, parti dell'implementazione sono esposte. self.__class__, self.__dict__E altre strutture "interni" sono disponibili in modo evidente.

È per minimizzare la differenza tra metodi e funzioni. Consente di generare facilmente metodi in metaclasse o di aggiungere metodi in fase di esecuzione a classi preesistenti.

per esempio

>>> class C(object):
...     def foo(self):
...         print "Hi!"
...
>>>
>>> def bar(self):
...     print "Bork bork bork!"
...
>>>
>>> c = C()
>>> C.bar = bar
>>> c.bar()
Bork bork bork!
>>> c.foo()
Hi!
>>>

Inoltre (per quanto ne so) semplifica l'implementazione del runtime di Python.

Suggerisco di leggere il blog di Guido van Rossum su questo argomento - Perché il sé esplicito deve rimanere .

Quando viene decorata una definizione di metodo, non sappiamo se assegnargli automaticamente un parametro 'self' oppure no: il decoratore potrebbe trasformare la funzione in un metodo statico (che non ha 'self') o un metodo di classe (che ha un tipo di sé divertente che si riferisce a una classe anziché a un'istanza), oppure potrebbe fare qualcosa di completamente diverso (è banale scrivere un decoratore che implementa '@classmethod' o '@staticmethod' in puro Python). Non c'è modo senza sapere cosa fa il decoratore se dotare il metodo di essere definito con un argomento implicito "sé" o no.

Respingo gli hack come "@classmethod" e "@staticmethod".

Python non ti costringe a usare "self". Puoi dargli qualunque nome tu voglia. Devi solo ricordare che il primo argomento in un'intestazione di definizione del metodo è un riferimento all'oggetto.

Ti permette anche di fare questo: (in breve, invocare Outer(3).create_inner_class(4)().weird_sum_with_closure_scope(5)restituirà 12, ma lo farà nel modo più folle.

class Outer(object):
    def __init__(self, outer_num):
        self.outer_num = outer_num

    def create_inner_class(outer_self, inner_arg):
        class Inner(object):
            inner_arg = inner_arg
            def weird_sum_with_closure_scope(inner_self, num)
                return num + outer_self.outer_num + inner_arg
        return Inner

Ovviamente, questo è più difficile da immaginare in linguaggi come Java e C #. Rendendo esplicito il riferimento personale, sei libero di fare riferimento a qualsiasi oggetto con quel riferimento automatico. Inoltre, un tale modo di giocare con le classi in fase di esecuzione è più difficile da fare nei linguaggi più statici - non è necessariamente buono o cattivo. È solo che il sé esplicito permette a tutta questa follia di esistere.

Inoltre, immagina questo: vorremmo personalizzare il comportamento dei metodi (per la profilazione o qualche pazza magia nera). Questo può portarci a pensare: e se avessimo una classe il Methodcui comportamento potremmo ignorare o controllare?

Bene eccolo qui:

from functools import partial

class MagicMethod(object):
    """Does black magic when called"""
    def __get__(self, obj, obj_type):
        # This binds the <other> class instance to the <innocent_self> parameter
        # of the method MagicMethod.invoke
        return partial(self.invoke, obj)


    def invoke(magic_self, innocent_self, *args, **kwargs):
        # do black magic here
        ...
        print magic_self, innocent_self, args, kwargs

class InnocentClass(object):
    magic_method = MagicMethod()

E ora: InnocentClass().magic_method()agirà come previsto. Il metodo verrà associato con il innocent_selfparametro to InnocentClasse con l' magic_selfistanza MagicMethod. Strano eh? È come avere 2 parole chiave this1e this2in lingue come Java e C #. Magia come questa consente ai framework di fare cose che altrimenti sarebbero molto più dettagliate.

Ancora una volta, non voglio commentare l'etica di questa roba. Volevo solo mostrare cose che sarebbero più difficili da fare senza un esplicito riferimento di sé.

Penso che la vera ragione oltre a "The Zen of Python" sia che le funzioni sono cittadini di prima classe in Python.

Il che essenzialmente li rende un oggetto. Ora il problema fondamentale è se le tue funzioni sono anche oggetti, nel paradigma orientato agli oggetti come invieresti messaggi agli oggetti quando i messaggi stessi sono oggetti?

Sembra un problema con le uova di gallina, per ridurre questo paradosso, l'unico modo possibile è passare un contesto di esecuzione ai metodi o rilevarlo. Ma dal momento che Python può avere funzioni nidificate, sarebbe impossibile farlo poiché il contesto dell'esecuzione cambierebbe per le funzioni interne.

Questo significa che l'unica soluzione possibile è passare esplicitamente 'sé' (Il contesto dell'esecuzione).

Quindi credo che sia un problema di implementazione lo Zen è arrivato molto più tardi.

Penso che abbia a che fare con PEP 227:

I nomi nell'ambito della classe non sono accessibili. I nomi vengono risolti nell'ambito della funzione di chiusura più interna. Se una definizione di classe si verifica in una catena di ambiti nidificati, il processo di risoluzione salta le definizioni di classe. Questa regola impedisce interazioni dispari tra gli attributi di classe e l'accesso alle variabili locali. Se si verifica un'operazione di associazione dei nomi in una definizione di classe, crea un attributo sull'oggetto classe risultante. Per accedere a questa variabile in un metodo o in una funzione nidificata all'interno di un metodo, è necessario utilizzare un riferimento all'attributo, tramite sé o tramite il nome della classe.

Come spiegato in sé in Python, Demysified

qualcosa come obj.meth (args) diventa Class.meth (obj, args). Il processo di chiamata è automatico mentre il processo di ricezione non lo è (è esplicito). Questo è il motivo per cui il primo parametro di una funzione in classe deve essere l'oggetto stesso.

class Point(object):
    def __init__(self,x = 0,y = 0):
        self.x = x
        self.y = y

    def distance(self):
        """Find distance from origin"""
        return (self.x**2 + self.y**2) ** 0.5

invocazioni:

>>> p1 = Point(6,8)
>>> p1.distance()
10.0

dentro () definisce tre parametri ma ne abbiamo appena passati due (6 e 8). Allo stesso modo distance () richiede uno ma sono stati passati zero argomenti.

Perché Python non si lamenta di questa mancata corrispondenza del numero di argomenti ?

Generalmente, quando chiamiamo un metodo con alcuni argomenti, la funzione di classe corrispondente viene chiamata posizionando l'oggetto del metodo prima del primo argomento. Quindi, qualsiasi cosa come obj.meth (args) diventa Class.meth (obj, args). Il processo di chiamata è automatico mentre il processo di ricezione non lo è (è esplicito).

Questo è il motivo per cui il primo parametro di una funzione in classe deve essere l'oggetto stesso. Scrivere questo parametro come self è semplicemente una convenzione . Non è una parola chiave e non ha un significato speciale in Python. Potremmo usare altri nomi (come questo) ma ti consiglio vivamente di non farlo. L'uso di nomi diversi da self è disapprovato dalla maggior parte degli sviluppatori e degrada la leggibilità del codice ("La leggibilità conta").
...
In, il primo esempio self.x è un attributo di istanza mentre x è una variabile locale. Non sono gli stessi e si trovano in spazi dei nomi diversi.

Il Sé è qui per restare

Molti hanno proposto di rendere self una parola chiave in Python, come questa in C ++ e Java. Ciò eliminerebbe l'uso ridondante di sé esplicito dall'elenco formale dei parametri nei metodi. Mentre questa idea sembra promettente, non accadrà. Almeno non nel prossimo futuro. Il motivo principale è la compatibilità con le versioni precedenti . Ecco un blog del creatore di Python stesso che spiega perché l'io esplicito deve rimanere.

C'è anche un'altra risposta molto semplice: secondo lo zen di Python , "esplicito è meglio che implicito".