noob question: "TypeError" wrong number of args

[Bruno Desthuilliers]

Edward Elliott a écrit :
> Bruno Desthuilliers wrote:
> 
>>Edward, I know I told you so at least three times, but really,
>>seriously, do *yourself* a favor : take time to read about descriptors
>>and metaclasses - and if possible to experiment a bit - so you can get a
>>better understanding of Python's object model. Then I'll be happy to
>>continue this discussion (.
>  
> Will do, if nothing else it will eliminate language barriers, which we may
> be running into at this point (though you've indicated otherwise).  

You won't regret it anyway - my own experience is that you must go thru 
this to really take full advantage of Python's power, expressivity and 
flexibility.

Oh, and, yes : it's definitively fun too !-)

>  I appreciate your
> patience and willingness to engage in this discussion.

<humble>
Votre serviteur, Messire.
</humble>

> As a last ditch effort to get my point across:
> 
> Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point
> something has to translate this source code
>   def method (self, a, b): something
> into a function object (or whatever you're calling the runnable code this
> week). 

AFAIK, this is done by partly by the compiler and partly by the interpreter.

> Call this translator Foo.  Whatever Foo is, it can insert 'self'
> into the parameter list for method, 

This would have to happen before compilation - I'd say at parsing time. 
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.

> e.g. when it sees "def method (a,b)"

This has to be in a class statement - else it's shouldn't be touched.

> it
> pretend like it saw "def method (self,a,b)" and proceed as usual.  Once it
> does that, everything is exactly the same as before.
> 
> 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... 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 don't know enough about Python's parser to tell if it could 
work and how hard this would be.

> Next run the output source code with the normal Python interpreter. 
> Everything functions *exactly* as before because the code is *exactly* the
> same as what you would have written if you'd put the 'self's in there
> manually.  Now make the Python interpreter invoke this text processor as
> the first step in processing source code.  Voila, python + implicit self.  

cf above.

> No changes to the object model.
seems not.

> No changes to dynamic binding.
idem

> Same "runnable" code as before.
seems so.

> Where is the problem in this scheme?
> Or (since I haven't read up on the object model yet) simply: Is there a
> problem?

Apart from the added complexity to the parser, I don't find one righ now 
- but note that there may as well be something obviously wrong that I 
fail to spot (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.

Well, I must admit that done this way (which is quite different from 
what I understood from your previous posts), this could *perhaps* 
(unless I missed something - any guru around here ?) work. At least it 
does not sound so crazy.

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 !-)

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. 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...

Ok, time to bed now - I'll re-read this when my one and only neuron left 
will be willing and able to do its job !-)