[Python-Dev] Draft proposal: Implicit self in Python 3.0 (original) (raw)

Ian Bicking ianb at colorstudy.com
Fri Jan 6 18:14:28 CET 2006

Nick Coghlan wrote: [...]

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?

I think this might return things very similar to what are returned now. The only reasonable alternative I can think of is that Foo.bar would return something that simply could not be called until it was bound, so this:

inst = Foo() f = Foo.bar print f(inst, 1, 2)

would have to be translated to this this:

inst = Foo() f = Foo.bar meth = bind(f, inst) print meth(1, 2)

It seems clear given the rest of the proposal that this second form will work, it's just a question of whether the first form will work at all. Personally I find the first form is rather uncommon anyway, and 50% of the time I write it it's a bug. So the more explicit second form would be fine with me. Well... it becomes more complex for decorators, I guess:

def printargs(func): def replacement(*args, **kw): print args, kw return func(*args, **kw) return replacement class Foo: @printargs def null(a): pass

What is printargs going to print? Will it even work? I'd guess you'd have to do:

def printargs(func): def replacement(*args, **kw): print args, kw return bind(func, self)(*args, **kw) return replacement

But what does that do if you apply printargs to a function that isn't a method? I generally have found it awkard to apply decorators to both methods and functions, except when the decorators pass through all the arguments unchanged (as printargs does). But I don't know if this is an improvement; I guess it depends on what bind(func, self) does outside of a method invocation. I think self should be undefined in that case. Well, I guess you could do:

def printargs(func): def replacement(*args, **kw): print args, kw try: bound = bind(func, self, class) except NameError: try: bound = bind(func, None, class) except NameError: bound = func return bound(*args, **kw) return replacement

Ugh.

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.

I disagree; I'm 100% comfortable and have internalized Python's use of an explicit self parameter, but it still doesn't feel more explicit or practical than the traditional way of writing out methods in other languages. I'm inclined to say that this might be too substantial of a change to Python, but I don't think the current way method definitions work is particular elegant, and it hasn't really grown on me over all these years. I still frequently spell method signatures incorrectly. And I can't explain the current situation to a new user, except to say "this is just the way it is", because the explanation only makes sense when you are much further into the language. And don't get me started on the error messages when you get the parameter count wrong...

(As an aside directed at the original PEP, I think discussion of leaving self out of expressions, e.g., ".x" for "self.x", should be separate from the rest of this PEP).

-- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org

More information about the Python-Dev mailing list