Python/Pirate status

[Sam Ruby]

By creating python specific PMCs, I got the pirate tests to pass, where 
pass is defined as producing the exact same output as CPython produces 
with the same input files.

These python specific pmcs were initally clones of perl specific PMCs, 
with just enough added functionality (example: repr methods) to make 
them work, and essentially hardwiring in PARROT_PYTHON_MODE in these 
PMCs.  Everything works without the "--python" flag, including 
generators.  (In fact, I suspect that generators won't work with the 
--python flag).

Once this was done, I then gutted each pmc, and then incrementally added 
back in only those methods that were required to pass the unit tests. 
This forced me to do a code review, and will help to identify test 
coverage holes.  My feeling is that the smaller set of PMCs, backed by 
test cases, will be easier to refactor and improve on.

I'm now converting to dynclasses.  To be honest, I'm not thrilled with 
this.  What I would really prefer is a Parrot_new_p_s opcode with the 
runtime worrying about caching class names across sub and module boundaries.

Once this is done, I'll commit the classes to the parrot cvs, and then 
commit the corresponding changes to the pirate cvs.

After that, there are a number of directions I want to head.  I want to 
refactor bits of Pirate into exploiting methods that are attached to a 
singleton builtin object (example: range).  I want to build test cases 
to cover every exposed method on every object (an example for int is 
attached).  I want to pass the CPython test suite.  And pass the 
parrot/languages/python/t/pie tests.

- Sam Ruby