Partially fix test_class in p3yk. This allows the test
to be actually run, although it could also be solved by
allowing 'exec' to receive any dict-like object
(there's a patch for that elsewhere, slated for 2.5, I
believe, but dictproxy objects would have to grow
setitem support for it to work.) Me, I prefer setattr()
like this over mucking with __dict__, although I have
to admit it did find a potential bug :) (The issue is
that class.__dict__ is a dictproxy object, if class is
a newstyle class.)

There are, however, more problems with test_class that
this doesn't resolve:

 - Classic classes that have a __cmp__ or __eq__
method, but no __hash__ method, are unhashable. The
same is not true for new-style classes. I'm not sure
whether that's a bug in new-style classes, or
desireable behaviour.

 - The recursive-__call__ test (where Ainst.__call__ ==
Ainst, so the hunt for the actual code to run is
recursive) crashes Python on my machine. The test
doesn't crash for classic classes. It seems to be a
stack overflow, or some other memory corruption scheme,
but I'll have to find me a machine with less address
space and memory to more comfortly debug this (talk
about a luxury problem!)

 - __coerce__ isn't being called. I don't recall
whether that's a newstyle-class issue, or a py3k
decision, or a bug. If it isn't a bug, output just has
to be regenerated.

 - Output has to be regenerated to pick up __truediv__
and __rtruediv__ instead of __div__ and __rdiv__.

Logged In: YES 
user_id=34209

Checked in this fix, still leaves the other issues open.

Logged In: YES 
user_id=764593

It was correct not to call coerce.

According to the documentation in abstract.c just above 
binary_op1 and ternary_op, coerce is not called unless at 
least one of the objects is old-style.

Should coerce therefore also be removed from builtins?