Lors de la définition d'une méthode sur une classe en Python, cela ressemble à ceci:

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

Mais dans certains autres langages, tels que C #, vous avez une référence à l'objet auquel la méthode est liée avec le mot clé "this" sans le déclarer comme argument dans le prototype de la méthode.

Était-ce une décision intentionnelle de conception de langage en Python ou y a-t-il des détails d'implémentation qui nécessitent le passage de "self" comme argument?

J'aime citer le Zen de Python de Peters. "Explicite vaut mieux qu'implicite."

En Java et C ++, 'this. ' peut être déduit, sauf lorsque vous avez des noms de variables qui ne permettent pas de déduire. Vous en avez donc parfois besoin et parfois pas.

Python choisit de rendre des choses comme cela explicites plutôt que basées sur une règle.

De plus, comme rien n'est implicite ou supposé, des parties de l'implémentation sont exposées. self.__class__, self.__dict__et d'autres structures "internes" sont disponibles de manière évidente.

C'est pour minimiser la différence entre les méthodes et les fonctions. Il vous permet de générer facilement des méthodes dans des métaclasses ou d'ajouter des méthodes au moment de l'exécution à des classes préexistantes.

par exemple

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

Cela (à ma connaissance) facilite également l'implémentation du runtime python.

Je suggère que l'on lise le blog de Guido van Rossum sur ce sujet - Pourquoi l'auto explicite doit rester .

Lorsqu'une définition de méthode est décorée, nous ne savons pas si lui donner automatiquement un paramètre «self» ou non: le décorateur pourrait transformer la fonction en une méthode statique (qui n'a pas de «self»), ou une méthode de classe (qui a un drôle de soi qui fait référence à une classe au lieu d'une instance), ou il pourrait faire quelque chose de complètement différent (il est trivial d'écrire un décorateur qui implémente '@classmethod' ou '@staticmethod' en Python pur). Il n'y a aucun moyen sans savoir ce que fait le décorateur de doter la méthode définie d'un argument implicite de «soi» ou non.

Je rejette les hacks comme le casse spéciale '@classmethod' et '@staticmethod'.

Python ne vous oblige pas à utiliser "self". Vous pouvez lui donner le nom que vous voulez. Vous devez juste vous rappeler que le premier argument dans un en-tête de définition de méthode est une référence à l'objet.

Vous permet également de faire ceci: (en bref, invoquer Outer(3).create_inner_class(4)().weird_sum_with_closure_scope(5)retournera 12, mais le fera de la manière la plus 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

Bien sûr, c'est plus difficile à imaginer dans des langages comme Java et C #. En rendant l'auto-référence explicite, vous êtes libre de faire référence à n'importe quel objet par cette auto-référence. De plus, une telle façon de jouer avec des classes à l'exécution est plus difficile à faire dans les langages les plus statiques - ce n'est pas nécessairement une bonne ou une mauvaise chose. C'est juste que le moi explicite permet à toute cette folie d'exister.

De plus, imaginez ceci: nous aimerions personnaliser le comportement des méthodes (pour le profilage, ou de la magie noire folle). Cela peut nous amener à penser: et si nous avions une classeMethod dont nous pouvions outrepasser ou contrôler le comportement?

Et bien voilà:

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

Et maintenant: InnocentClass().magic_method()agira comme prévu. La méthode sera liée au innocent_selfparamètre to InnocentClasset magic_selfà l'instance MagicMethod. Bizarre hein? C'est comme avoir 2 mots clés this1etthis2 dans des langages comme Java et C #. La magie comme celle-ci permet aux frameworks de faire des choses qui seraient autrement beaucoup plus verbeuses.

Encore une fois, je ne veux pas commenter l'éthique de ce genre de choses. Je voulais juste montrer des choses qui seraient plus difficiles à faire sans une référence explicite.

Je pense que la vraie raison en plus de "Le Zen de Python" est que les Fonctions sont des citoyens de première classe en Python.

Ce qui en fait essentiellement un objet. Maintenant, le problème fondamental est que si vos fonctions sont également des objets, dans le paradigme orienté objet, comment enverriez-vous des messages aux objets lorsque les messages eux-mêmes sont des objets?

Ressemble à un problème d'oeuf de poule, pour réduire ce paradoxe, la seule façon possible est de passer un contexte d'exécution aux méthodes ou de le détecter. Mais comme python peut avoir des fonctions imbriquées, il serait impossible de le faire car le contexte d'exécution changerait pour les fonctions internes.

Cela signifie que la seule solution possible est de passer explicitement «soi» (le contexte d'exécution).

Je pense donc que c'est un problème de mise en œuvre que le Zen est venu beaucoup plus tard.

Je pense que cela a à voir avec le PEP 227:

Les noms dans la portée de classe ne sont pas accessibles. Les noms sont résolus dans l'étendue de fonction englobante la plus interne. Si une définition de classe se produit dans une chaîne d'étendues imbriquées, le processus de résolution ignore les définitions de classe. Cette règle empêche les interactions étranges entre les attributs de classe et l'accès aux variables locales. Si une opération de liaison de nom se produit dans une définition de classe, elle crée un attribut sur l'objet de classe résultant. Pour accéder à cette variable dans une méthode, ou dans une fonction imbriquée dans une méthode, une référence d'attribut doit être utilisée, soit via self, soit via le nom de classe.

Comme expliqué dans self en Python, Demystified

quelque chose comme obj.meth (args) devient Class.meth (obj, args). Le processus appelant est automatique tandis que le processus récepteur ne l'est pas (son explicite). C'est la raison pour laquelle le premier paramètre d'une fonction en classe doit être l'objet lui-même.

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

Invocations:

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

init () définit trois paramètres mais nous venons d'en passer deux (6 et 8). De même distance () nécessite un mais aucun argument n'a été passé.

Pourquoi Python ne se plaint-il pas de cette différence de nombre d'arguments ?

Généralement, lorsque nous appelons une méthode avec quelques arguments, la fonction de classe correspondante est appelée en plaçant l'objet de la méthode avant le premier argument. Donc, quelque chose comme obj.meth (args) devient Class.meth (obj, args). Le processus appelant est automatique tandis que le processus récepteur ne l'est pas (son explicite).

C'est la raison pour laquelle le premier paramètre d'une fonction en classe doit être l'objet lui-même. L'écriture de ce paramètre en tant que self n'est qu'une convention . Ce n'est pas un mot-clé et n'a pas de signification particulière en Python. Nous pourrions utiliser d'autres noms (comme celui-ci) mais je vous suggère fortement de ne pas le faire. L'utilisation de noms autres que self est mal vue par la plupart des développeurs et dégrade la lisibilité du code ("La lisibilité compte").
...
Dans, le premier exemple self.x est un attribut d'instance tandis que x est une variable locale. Ils ne sont pas identiques et se trouvent dans des espaces de noms différents.

Le moi est là pour rester

Beaucoup ont proposé de faire de soi un mot-clé en Python, comme celui-ci en C ++ et Java. Cela éliminerait l'utilisation redondante de soi explicite de la liste de paramètres formelle dans les méthodes. Bien que cette idée semble prometteuse, elle ne se réalisera pas. Du moins pas dans un avenir proche. La raison principale est la compatibilité descendante . Voici un blog du créateur de Python lui-même expliquant pourquoi le moi explicite doit rester.

Il y a aussi une autre réponse très simple: selon le zen du python , "explicite vaut mieux qu'implicite".