[Python-Dev] Draft proposal: Implicit self in Python 3.0

[Nick Coghlan]

Alexander Kozlovsky wrote:
> Hello!
> 
> I have some proposal for Python 3.0 (interesting one, from my point
> of view). I'm sorry for my English, it is not very good.

Your English seems fine. About the only thing I noticed is that you have the 
meaning of 'function arguments' vs 'function parameters' switched from a 
Python point of view - the parameters are defined as part of the function 
definition, while the arguments are provided at call time. This is really a 
minor semantic quibble though - I expect most people wouldn't have any real 
trouble figuring out what you meant.

Even though I still disagree with it, this is one of the better reasoned "no 
explicit self" proposals I've encountered - even if Guido ends up not liking 
it, I believe it should still be recorded as a PEP on python.org.

To sum the proposal up in my own words:
   Eliminate the need for explicit class and self slots in class and instance 
methods by implicitly providing those slots on all functions.

The main concern I have is with the answer to the question "How many 
positional arguments does the function have if I retrieve it from the class, 
rather than from an instance?" (this is the common concern for almost all 
proposals to remove the explicit self and class_ slots).

That is, the rationale for requiring the explicit self is an outgrowth of the 
fact that methods can be retrieved directly from the class:

      class Foo:
          def __init__(self, x):   # 1: Explicit 'self' argument
              self.x = x           # 2: 'self' must be used explicitly
          def bar(self, a, b):     # 3: There are three parameters...
              print self.x + a + b

      f = Foo.bar                  # We retrieve the unbound method
      f(Foo(10), 20, 30)           # And there are three arguments at call time
      f = Foo().bar                # Using an instance binds the first argument
      f(20, 30)                    # Which means there are two arguments left

You can also bypass the type machinery entirely, and retrieve the raw function 
object from the class dictionary:

     f = Foo.__dict__["bar"] # This gives a function. . .
     f(Foo(10), 20, 30)      # which takes three arguments as written

Under the proposal being discussed, things become far less clear:

     class Foo:
         def __init__(x):         # 1: Implicit self
             .x = x               # 2: Brief form of: self.x = x
         def bar(a, b):           # 3: Two arguments...
             print .x + a + b

     f = Foo(10).bar              # We agree this accepts 2 arguments
     f = Foo.bar                  # How many arguments does f accept?
     f = Foo.__dict__["bar"]      # How many arguments does it accept now?

The answer to the first question *has* to be 3, or we lose too much 
functionality - but that's seriously surprising (the method appears to require 
two arguments when its defined, but actually requires 3 due to its being 
retrieved from a class). And it still requires that a distinction be made 
between instance, class and static methods in order to control the signature 
of the retrieved method.

However, that answer creates its own problems - what if we have a 3-argument 
function that does exactly what we want our method to do? We'd need some way 
of signalling to the class that the function should be left alone when being 
retrieved from the class, but have the first argument bound automatically when 
being retrieved from an instance.

This is where the "Explicit is better than implicit" and "Practicality beats 
purity" *both* kick in in favour of explicit self and class_ parameters - the 
signature of the retrieved function is exactly what the source code says it 
is, because there aren't any implicit parameters getting slipped into the 
parameter list when you aren't looking.

As I see it, the real issue is that people are often coming from a Java or C++ 
background where you can't manipulate functions and classes as first-class 
objects - the idea that the instance method signature could be written to 
describe the signature of the unbound method returned by "Foo.bar" rather than 
the bound method returned by "Foo().bar" is an entirely foreign concept.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org