Al definir un método en una clase en Python, se ve así:

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

Pero en algunos otros lenguajes, como C #, tiene una referencia al objeto al que está vinculado el método con la palabra clave "this" sin declararlo como un argumento en el prototipo del método.

¿Fue esta una decisión intencional de diseño de lenguaje en Python o hay algunos detalles de implementación que requieren la aprobación de "self" como argumento?

Me gusta citar el Zen de Python de Peters. "Explícito es mejor que implícito".

En Java y C ++, ' this.' se puede deducir, excepto cuando tiene nombres de variables que hacen que sea imposible de deducir. Entonces a veces lo necesitas y a veces no.

Python elige hacer que cosas como esta sean explícitas en lugar de basarse en una regla.

Además, dado que no se implica ni se supone nada, se exponen partes de la implementación. self.__class__, self.__dict__y otras estructuras "internas" están disponibles de manera obvia.

Es para minimizar la diferencia entre métodos y funciones. Le permite generar fácilmente métodos en metaclases o agregar métodos en tiempo de ejecución a clases preexistentes.

p.ej

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

También (hasta donde yo sé) facilita la implementación del tiempo de ejecución de Python.

Sugiero que se lea el blog de Guido van Rossum sobre este tema: por qué el ser explícito tiene que quedarse .

Cuando se decora una definición de método, no sabemos si asignarle automáticamente un parámetro 'self' o no: el decorador podría convertir la función en un método estático (que no tiene 'self'), o un método de clase (que tiene un tipo divertido de sí mismo que se refiere a una clase en lugar de una instancia), o podría hacer algo completamente diferente (es trivial escribir un decorador que implemente '@classmethod' o '@staticmethod' en Python puro). No hay manera sin saber lo que hace el decorador para dotar al método que se está definiendo con un argumento implícito de "sí mismo" o no.

Rechazo los hacks como las carcasas especiales '@classmethod' y '@staticmethod'.

Python no te obliga a usar "self". Puedes darle el nombre que quieras. Solo debe recordar que el primer argumento en un encabezado de definición de método es una referencia al objeto.

También le permite hacer esto: (en resumen, la invocación Outer(3).create_inner_class(4)().weird_sum_with_closure_scope(5)devolverá 12, pero lo hará de la manera más loca.

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

Por supuesto, esto es más difícil de imaginar en lenguajes como Java y C #. Al hacer explícita la autorreferencia, puede referirse a cualquier objeto mediante esa autorreferencia. Además, tal forma de jugar con las clases en tiempo de ejecución es más difícil de hacer en los idiomas más estáticos, no es necesariamente bueno o malo. Es solo que el ser explícito permite que exista toda esta locura.

Además, imagine esto: nos gustaría personalizar el comportamiento de los métodos (para perfilar, o alguna magia negra loca). Esto puede llevarnos a pensar: ¿qué pasaría si tuviéramos una clase Methodcuyo comportamiento podríamos anular o controlar?

Pues aquí está:

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

Y ahora: InnocentClass().magic_method()actuará como se esperaba. El método estará vinculado con el innocent_selfparámetro a InnocentClass, y con la magic_selfinstancia de MagicMethod. Raro eh? Es como tener 2 palabras clave this1y this2en lenguajes como Java y C #. Magia como esta permite que los frameworks hagan cosas que de otro modo serían mucho más detalladas.

Nuevamente, no quiero comentar sobre la ética de estas cosas. Solo quería mostrar cosas que serían más difíciles de hacer sin una autorreferencia explícita.

Creo que la verdadera razón además de "The Zen of Python" es que las funciones son ciudadanos de primera clase en Python.

Lo que esencialmente los convierte en un Objeto. Ahora, el problema fundamental es si sus funciones también son objeto, entonces, en el paradigma orientado a objetos, ¿cómo enviaría mensajes a los objetos cuando los mensajes mismos son objetos?

Parece un problema de huevo de gallina, para reducir esta paradoja, la única forma posible es pasar un contexto de ejecución a los métodos o detectarlo. Pero dado que Python puede tener funciones anidadas, sería imposible hacerlo ya que el contexto de ejecución cambiaría para las funciones internas.

Esto significa que la única solución posible es pasar explícitamente 'self' (El contexto de ejecución).

Así que creo que es un problema de implementación, el Zen llegó mucho más tarde.

Creo que tiene que ver con PEP 227:

Los nombres en el alcance de la clase no son accesibles. Los nombres se resuelven en el ámbito de la función de encierro más interna. Si se produce una definición de clase en una cadena de ámbitos anidados, el proceso de resolución omite las definiciones de clase. Esta regla evita interacciones extrañas entre los atributos de clase y el acceso a la variable local. Si se produce una operación de enlace de nombre en una definición de clase, crea un atributo en el objeto de clase resultante. Para acceder a esta variable en un método, o en una función anidada dentro de un método, se debe utilizar una referencia de atributo, ya sea por sí mismo o por el nombre de la clase.

Como se explica en sí mismo en Python, desmitificado

cualquier cosa como obj.meth (args) se convierte en Class.meth (obj, args). El proceso de llamada es automático mientras que el proceso de recepción no lo es (es explícito). Esta es la razón por la cual el primer parámetro de una función en la clase debe ser el objeto mismo.

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

Invocaciones

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

init () define tres parámetros pero acabamos de pasar dos (6 y 8). De manera similar, la distancia () requiere uno, pero se pasaron cero argumentos.

¿Por qué Python no se queja de esta discrepancia de número de argumento ?

Generalmente, cuando llamamos a un método con algunos argumentos, la función de clase correspondiente se llama colocando el objeto del método antes del primer argumento. Entonces, cualquier cosa como obj.meth (args) se convierte en Class.meth (obj, args). El proceso de llamada es automático mientras que el proceso de recepción no lo es (es explícito).

Esta es la razón por la cual el primer parámetro de una función en la clase debe ser el objeto mismo. Escribir este parámetro como self es simplemente una convención . No es una palabra clave y no tiene un significado especial en Python. Podríamos usar otros nombres (como este) pero le sugiero encarecidamente que no lo haga. El uso de nombres que no sean self está mal visto por la mayoría de los desarrolladores y degrada la legibilidad del código ("La legibilidad cuenta").
...
En, el primer ejemplo self.x es un atributo de instancia, mientras que x es una variable local. No son lo mismo y se encuentran en diferentes espacios de nombres.

El yo está aquí para quedarse

Muchos han propuesto convertirse en una palabra clave en Python, como esta en C ++ y Java. Esto eliminaría el uso redundante de self explícito de la lista de parámetros formales en los métodos. Si bien esta idea parece prometedora, no va a suceder. Al menos no en el futuro cercano. La razón principal es la compatibilidad con versiones anteriores . Aquí hay un blog del creador del propio Python que explica por qué el yo explícito tiene que quedarse.

También hay otra respuesta muy simple: según el zen de python , "explícito es mejor que implícito".