noob question: "TypeError" wrong number of args

Edward Elliott nobody at
Wed May 3 21:42:35 CEST 2006

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.

More information about the Python-list mailing list