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
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
- Sam Ruby