noob question: "TypeError" wrong number of args

[Edward Elliott]

Steve Holden wrote:
> Objects don't actually "pass references to themselves". The interpreter
> adds the bound instance as the first argument to a call on a bound method.

Sure, if you want to get technical  For that matter, objects don't actually
call their methods either -- the interpreter looks up the method name in a
function table and dispatches it.  I don't see how shorthand talk about
objects as actors hurts anything unless we're implementing an interpreter.


> Sorry, it's a wart on your brain. 

Fine it's a wart on my brain.  It's still a wart.

> Read Guido's arguments in favor of an 
> explicit self argument again before you assert this so confidently. 

I would if I could find it.  I'm sure he had good reasons, they may even
convince me.  But from my current perspective I disagree.  

> It's 
> certainly confusing to beginners, but there are actually quite sound
> reasons for it (see next paragraph).

While confusion for beginners is a problem, that's not such a big deal. 
It's a trivial fix that they see once and remember forever.  What I mind is
its ugliness, that the language makes me do work declaring self when it
knows damn well it won't like my code until I do what it wants (yes I'm
anthropomorphizing interpreters now).  The interpreter works for me, I
don't work for it.  Things it can figure out automatically, it should
handle.

 
> Hmm. I see. How would you then handle the use of unbound methods as
> first-class objects? If self is implicitly declared, that implies that
> methods can only be used when bound to instances.

I fail to see the problem here.  I'm taking about implicit declaration on
the receiving end.  It sounds like you're talking about implicit passing on
the sending end.  The two are orthogonal.  I can declare
    def amethod (a, b):
and have self received implicitly (i.e. get the object instance bound by the
interpreter to the name self).  The sender still explicitly provides the
object instance, e.g.
    obj.amethod (a,b)
or
    class.amethod (obj, a, b)
IOW everything can still work exactly as it does now, only *without me
typing self* as the first parameter of every goddamn method I write.  Does
that make sense?

> How, otherwise, would 
> you have an instance call its superclass's __init__ method if it's no
> longer valid to say
> 
>      myClass(otherClass):
>          def __init__(self):
>              otherClass.__init__(self)
>              ...
> 

Like this:
      myClass(otherClass):
          def __init__():
              otherClass.__init__(self)

self is still there and still bound, I just don't have to type it out.  The
interpreter knows where it goes and what it does, automate it already!

>> * technically modules may be objects also, but in practice you don't
>> declare self as a parameter to module functions
> 
> The reason you don't do that is because the functions in a module are
> functions in a module, not methods of (some instance of) a class.
> Modules not only "may be" objects, they *are* objects, but the functions
> defined in them aren't methods. What, in Python, *isn't* an object?

If it looks like a duck and it quacks like a duck... Functions and methods
look different in their declaration but the calling syntax is the same. 
It's not obvious from the dot notation syntax where the 'self' argument
comes from.  Some interpreter magic goes on behind the scenes.  Great, I'm
all for it, now why not extend that magic a little bit further?