1) because we haven't seen the types multiple times yet,
so creating a new function specialization could be wasteful, and
2) the interpreter can't make use of the type specialization.

Specializing at the interpreter does let us start counting how
many times each specialization is used, and the function entry
counts are the only way we have right now of telling that a
particular specialization should be moved to a higher tier.
But I don't think we should do that using this mechanism.

ex:

for i in xrange(5):
    pass
else:
    return 2
"unreachable here!"

We didn't prune the "unreachable here" line, which caused
some issues.  I guess we could also support compiling
trivially-unreachable blocks.

- Allow unicode arguments to str.encode/str.decode
- Detect float parsing errors
- 'VAR_WITH_UNDERSCORES'.isupper() should be True
- str.rpartition()
- Switch to CPythons str.split

(ignore things that are clearly not importable)

Move stat.h include into pyport.h

I think there's a theoretical issue where a GC happens between the
assignment to a static slot and the call to PyGC_AddRoot.  I don't
think this was causing any issues, but I think it possibly could.

Add a few 'long' methods, support tuple sublasses, add uuid test and fix a _struct GC bug

I don't know how well this is followed in practice, but "!"
is supposed to just be for irgen-specific names that should
not make it to other tiers.  The closure and generator variables
are more like part of the inter-tier contract, so I think make more
sense as "#" names.

Add the zipimport, csv and ssl module

and let file.next() raise a StopException when on the end
To make the csv module work on files.

travis try enabling apt cache

Add bytearray and add a memoryview test

don't let AttributeError exceptions bubble out of softspace.  fixes fasta.py

virtualenv fixes

implement PyNumber_Divmod to fix datetime.timedelta(0)

Add unichr()

make tester produce useful help messages