[pypy-dev] type problems

[Michael Hudson]

I wrote this on the train yesterday.  Some of it is a bit out of date 
from talking on IRC today, but not all of it.

A tip for making the multimethod implementation more comprehensible: 
separate finding the method to call from calling it.  Also, 
consistently using common lisp terminology would help *me*, if no-one 
else.  And, finally, presuming that the implementation isn't going to 
change drastically another four or five times, documentation would be 
good!  As Samuele and Armin are probably too close to write this, 
perhaps I'll have a stab.  Also, disentangling them from the 
StdObjSpace implementation (if possible) would probably reduce the 
general level of incomprehension.

I want a spec for the applicable method computation algorithm -- a 
sufficiently detailed description to allow implementation by someone 
unfamiliar with our present one.  I would also like an explanation of 
why our algorithm is so flaming complicated.

(Having pdbed through a method selection, I do now have some 
understanding of why we're so slow!!)

Refactor!  Refactor!  Refactor!

And, after all that, the problem I was chasing wasn't in the 
multimethod implementation after all.  Heh.

There are problems will the space.call multimethod, or rather the bound 
variants of it: you can't translate

     o.__call__(a, b, c)

into

     space.call(o, a, b, c)

!  Another irregular multimethod?

I've also hacked on the test rig some more, adding an (optional) 
interactive mode that you get dropped into when there are failures.  
Currently it allows you to print each traceback individually (or as a 
group) and drop into a pdb session at the point of each failure.  I've 
also added a skeletal PyPy-specialized version of pdb, which will 
probably grow over time...

Debugging PyPy is ludicrously complicated: I know Python as well as 
almost anyone.  I know more about PyPy than just a very few people.  
I'm fairly smart.  And *I* get hopelessly lost in the internals.  What 
can we do about this?

Cheers,
M.