Added new anti8 example utility; used it to find and fix bugs

[pmaupin]

Berker:

I'm still pretty new at this git thing, so I probably didn't put this in as many separate commits as some would prefer. Feel free to slice and dice it anyway you want when updating the master. (I realize now that I should have done a branch before doing the work, as well, so that's something to try to do next time.)

Anyway, I wrote an example utility to be able to easily compare two source trees (e.g. before and after PEP8 modifications), and ran it on the 2.7 and 3.4 standard libraries, and exposed several bugs in codegen in the process.

For each bug, I wrote a failing testcase and then fixed the bug.

It might be worthwhile to do the same thing for 3.5 before your release, if the goal of the release is 3.5 support. All you have to do is run the anti8 script with a single parameter that is the path to the system libraries.

It's well past my bedtime, so I don't think I'll have any more code for your new version.

Thanks, Pat

[berkerpeksag]

This looks great, thanks! Perhaps we can make anti8 a public module in astor and add a CLI for it:

$ astor anti8 <path>
# or 
$ python -m astor.anti8 <path>

[pmaupin]

That might be a good idea -- maybe we don't want a separate examples directory. We possibly also want a flag whether we want to actually output the code to a file, or simply read it all (and recompile from an internal buffer).

EDIT -- this might also be really good to make some of the tests cleaner, maybe?

I'm not sure about current best practices on making combined library / utility widgets -- do you know of a good example to follow?

BTW, I downloaded and built 3.5, and had to modify anti8 to work with it due to errors found in the 3.5 library source code. Some of the errors were deliberate, but some of them were things we need to fix in the library, so I filed issue #26.

[pmaupin]

Split out bug fixes into a new rebased pull request, and will put anti8 into another pull request to be named later.