noob question: "TypeError" wrong number of args

[Edward Elliott]

bruno at modulix wrote:
> Technically, they are still function objects. They are later wrapped
> into method descriptor objects (at lookup time IIRC, but ask a guru or
> read the doc to know for sure). And don't forget the case of nested
> functions...

I don't see how nested functions change anything.  If they're nested in a
method, they can access self, but the name mapping is done at runtime. 
Unless you mean a nested fucntion which is dynamically added as a method,
but that's the same case as the next one.

 
>>  If you're declaring
>> methods outside the class and adding them dynamically, I think you would
>> need to declare 'self' explicitly.
> 
> Of course. Virtually *any* function can be set as a method[1] outside
> the class statement scope, either directly on the class object or - with
> manual wrapping - on an individual instance. And it's important to keep
> this feature.

I wouldn't dream otherwise.

>> Well I'm assuming the rules for when to put 'self' in the parameter list
>> are simple enough to be automated.
> 
> They are still complex enough to require a real parser. And anyway,
> since this is a syntax change, this should be handled by the parser IMHO.

I agree, but it's good to keep options in mind.

> Honestly, I don't think it has much chance. I barely even notice typing
> 'self' or 'cls',   and I guess it's the same for most Python programmers
> - those who can't stand it probably use another language... And FWIW, I
> still prefer to keep consistency in functions definitions.

I have no doubt that's true for a lot of people.  Hell I probably prefer the
current approach because 1) it's not a big deal in practice, and 2) I can
use the shorter 'me' or 's' in place of self in my own code, which I
couldn't do under the change (well, I could add 'me = self' as the first
statement of any method, but that's clumsy).  My objections stem more from
an elegance standpoint.  Of course elegance is in the eye of the beholder.