The function PyCFunction_GetFunction(func) check func type should be
exactly PyCFunction_Type. PyCFunction_GET_FUNCTION(func) does not check
func type. But assumes func layout starts with PyCFunctionObject. i.e.
for allowing func to be PyCFunction_Type subclass.

This way an extension which subclasses PyCFunctionObject will get
into trouble using PyCFunction_GET_FUNCTION() on Pyston

the module is much faster than the python implementation
But I had to change the code a little bit because of our GC and more importantly because some of our types have different names etc...
I also noticed that we failed to to set capifunc.__module__ in a lot of cases which made pickle error

The main capi calling convention is to box all the positional
arguments into a tuple, and then pass the tuple to PyArg_ParseTuple
along with a format string that describes how to parse out the
arguments.

This ends up being pretty wasteful and misses all of the fast
argument-rearrangement that we are able to JIT out.  These unicode
functions are particularly egregious, since they use a helper
function that ends up having to dynamically generate the format
string to include the function name.

This commit is a very simple change gets some of the common cases:
in addition to the existing METH_O calling convention ('self' plus
one positional arg), add the METH_O2 and METH_O3 calling
conventions.  Plus add METH_D1/D2/D3 as additional flags that can
be or'd into the calling convention flags, which specify that there
should some number of default arguments.

This is pretty limited:
- only handles up to 3 arguments / defaults
- only handles "O" type specifiers (ie no unboxing of ints)
- only allows NULL as the default value
- doesn't give as much diagnostic info on error

The first two could be handled by passing the format string as part
of the function metadata instead of using it in the function body,
though this would mean having to add the ability to understand the
format strings.

The last two issues are tricky from an API perspective since they
would require a larger change to pass through variable-length data
structures.

So anyway, punt on those issues for now, and just use the simple
flag approach.  This cuts the function call overhead by about 4x
for the functions that it's applied to, which are some common ones:
string.count, unicode.count, unicode.startswith.
(endswith, [r]find, and [r]index should all get updated as well)

We were using a slightly different (flattened) version; not sure why.

Add a PYSTON_NOEXCEPT define that gets defined to "noexcept" in C++ mode,
and to the empty string in C mode.

I don't think 'extern "C"' implies noexcept.

This is partly for better performance when we know that a function cannot throw
an exception, but also as an annotation for us since the exception model is
the main difference between C land and Pyston land.

Vim substitution: %s/\(\<PyAPI_FUNC\>(.*).*(\([^)]\|\n\)*)\);/\1 PYSTON_NOEXCEPT;/gc
- This will catch almost all cases, except for functions not marked with PyAPI_FUNC
  and function definitions that have extra paretheses (in comments, usually)

Our previous directory names:
include/
lib_python/2.7/
lib_python/2.7_Modules/
lib_python/2.7_Objects/
lib_python/2.7_Python/

new directory names:
from_cpython/Include/
from_cpython/Lib/
from_cpython/Modules/
from_cpython/Objects/
from_cpython/Python/

Sorry for the huge diff, but I think this makes way more sense.

Starting to really hit critical mass in terms of having enough
API support that it's easier to copy additional API functions over.