it's fundamentally unmaintainable.  Should we throw away pyclbr, or rewrite
it using the AST?

API.

But shouldn't we kill this module?  How many pprint clones do we need?

(There are some other problems with test_class.py that aren't as
easily fixed. :-( )

- a line indented with tabs;
- a function named 'as'.

silently converts floats to integers when expecting integer values.

'dictproxy' (which is a read-only non-dict mapping type that can't be passed
to exec.)

The failures the test finds are behavioural differences between old- and
new-style classes that may or may not be intended.

expected, when dealing with new-style broken-iterators.

convert float arguments to integer-taking format characters, so fix the test
to expect the failure.

 - Expect a new-style class tree in the getclasstree test.

sooner for new-style broken-iterators, expect it to.

Add (equally superficial) >>=/<<= test in the process. Relies on floats that
should be extremely close to the int '6' printing as '6.0', but I believe
that's a valid assumption ;P

Since the broken iterators are now new-style classes, iter() was able to do
the valid-iterator check sooner (on instantiation instead of on first call),
making the tests blow up sooner than expected.

(New-style class behaviour was already thoroughly tested)

   printing differently.
 - Fix doctest for classic-class behaviour, make it test new-style behaviour
   on an implicitly-new-style class instead.

spaces for indentation. Adds a '-ttt' option to turn the errors back into
warnings; I'm not yet sure whether that's desireable for Py3K.

Also remove the magic for setting the size of tabs based on emacs/vim-style
comments. Python now always considers tabstops to be every-8-spaces.

Use *absolute* import now that it is required.  (Should this go into 2.5?  Hopefully not the bogus comment about using relative imports.  That was just to see if anyone was paying attention.)

Use relative imports in compiler package now that it is required.  (Should this go into 2.5 or should we do compiler.XXX?)

were some cases where an int was assumed.

Also had to change the string of the exception when dividing and int by zero.
Not sure what the best error message should be.  Currently
  5 / 0 yields the message: ZeroDivisionError: float division

That isn't entirely correct.  But I'm not sure what else to do.