noob question: "TypeError" wrong number of args

[Edward Elliott]

Bruno Desthuilliers wrote:
> But then, constructs like:
> 
> class Obj(object):
>    def method(...): ...
>    method = staticmethod(method)
> 
> or it's newer syntactic-sugar-version would become somewhat more
> difficult to parse properly - but I admit that this is beyond my
> knowledge.

Hmm, that'll take some thought.  I assume if you're making method static,
you don't declare a self parameter for it?  If so, it shouldn't be hard,
just have the parser mark the method as static or no as it parses, and when
it reaches the end of the class insert 'self' for non-static methods.  If a
normal method can be converted to a static method outside the class
definition, that case should work just as it does now.


>> e.g. when it sees "def method (a,b)"
> 
> This has to be in a class statement - else it's shouldn't be touched.

Exactly, that's why I called it method and not func.  If you're declaring
methods outside the class and adding them dynamically, I think you would
need to declare 'self' explicitly.  I'm ok with this because 1) when you're
going that route, an explicit signal that something "different" is
happening is a good thing, and 2) I have no problem with optimizing for the
common case.  Not everyone will agree on these points, obviously.

>> I can prove that assertion too: make a simple text processor that reads
>> Python source code and outputs the same source code with only one change:
>> insert the string 'self" as the first parameter of every "def
>> somemethod".
> 
> Not so simple: you have plain functions (outside class statements), and
> inner functions (inside def statements), and classmethods, and statict
> methods, and some other corner cases (like __new__()) to take into
> acccount... 

Well I'm assuming the rules for when to put 'self' in the parameter list are
simple enough to be automated.  In cases where they're not (e.g. dynamic
methods outside a class), I have no problem with an explicit self to signal
what's going on.  That's the price you pay for dynamism.

> As I said, this requires more than a simple pre-processor 
> and so would have to be done at parsing time since it requires parsing
> anyway.

I think you could make a go of it with regular expressions, but yes parsing
is the better approach.

> - but note that there may as well be something obviously wrong that I
> fail to spot 

ditto

> (it's very late here and I had a hard day !-). I of course 
> don't take into account the fact that this would break all existing
> Python code, which is unavoidable for such a syntactic change.

of course, which I'm sure means it will never happen, Python 3
notwithstanding.


> Well, I must admit that done this way (which is quite different from
> what I understood from your previous posts), 

That's my fault, I did a lot of hand-waving at first and probably
contradicted myself a couple times as I was describing the idea.


> Now is this something good is another point. I was about to argue that I
> don't like the implicitness of it, but 1/ this is how most OOPLs do (at
> least from a syntactic POV) and 2/ the fact is that the instance is
> implicitely passed at call time, so I guess I'm just way too intoxicated
> by so many years of Python programming to feel at ease with this !-)

I'm sure much ink will be (and has been) spilled on the subject.
 
> Since Python 3K is supposed to be the 'clean the warts and don't bother
> breaking compat' rewrite of Python, you may as well propose a PEP on
> this. 

Maybe that will be my summer project.  We'll see, I was really hoping to
write fewer briefs and more code.

> You'll have to really prove it doesn't break anything else in the 
> object model, have strong and articulate arguments to support your point
> (like proving this is really a common source of confusion for newbies),
> and I really doubt it'll be accepted anyway. But what...

It's definitely an uphill battle and I wonder if it's really worth the
effort.  We'll see.