that is just based off of pulling our latest release

str: use tp_as_sequence instead of tp_as_number

string is special in that it is a c++ type which has tp_as_number and tp_as_sequence.
This causes problems because when we fixup the slot dispatcher we will set the tp_as_number fields but not the
tp_as_sequence because setting both can cause problems.
Some extensions (e.g. numpy) require that we use the sq_* functions instead of nb_*.
Therefore clear the tp_as_number fields (except nb_remainder which cpython has set too because it is not part of
tp_as_sequence).

BoxIteratorGeneric call PyIter_Next() lazily

update virtualenv to the one which always sets zip_safe=False

We were fetching to eagerly which caused issues if the iterator got used for other stuff too

Update test results

Merge conflict between my pr that added the full test suite and Sun's that
fixed one of the tests.

Some work on the numpy test suite

[WIP] Some minor numpy fixing.

binop: use PyNumber_* for user defined classes

microptimization: mark _PyGC_generation0 as having a const address

I think it's most important that we do this for the first arg,
since CPython won't end up increffing it either.

Looked at all places it comes from and this looks safe
(it's alive at least as long as the other arguments).

We are now crashing on cpython_oldstyle_getattr_crash (a CPython crasher)
but that's not really the fault of this change.

Merge refcounting into master

this is an advantage for _PyObject_GC_TRACK
which before compiled to something like this:
        cmpq    $-2, -16(%rdi)
        jne     .LBB0_2
        movq    $-3, -16(%rdi)
        movq    _PyGC_generation0(%rip), %rax
        movq    %rax, -32(%rdi)
        movq    _PyGC_generation0(%rip), %rax
        movq    8(%rax), %rax
        movq    %rax, -24(%rdi)
        leaq    -32(%rdi), %rcx
        movq    %rcx, (%rax)
        movq    _PyGC_generation0(%rip), %rax
        movq    %rcx, 8(%rax)

and now compiles to
        cmpq    $-2, -16(%rdi)
        jne     .LBB0_2
        movq    $-3, -16(%rdi)
        movq    _PyGC_generation0(%rip), %rax
        movq    %rax, -32(%rdi)
        movq    8(%rax), %rcx
        movq    %rcx, -24(%rdi)
        leaq    -32(%rdi), %rdx
        movq    %rdx, (%rcx)
        movq    %rdx, 8(%rax)

notice that it had to load _PyGC_generation0 three times because the compiler had to assume that because of aliasing it got motified.
(and this loads actually showed up in profiling as somewhat expensive)

tuple: implement tp_as_sequence->sq_contains

this speeds up a simple numpy benchmark by about 10x.

Some cleanup for the refcounting merge

enable sqlalchemy_smalltest

I did not trigger this bug (also could not come up with a test) but just by inspecting the code I thought it's very suspicious.

But I did remove the assert(!exc_state.is_reraise) assert because it got hit in a legitimate case,
(c++ exception got rethrowen in the llvm tier, cought in our c++ code and rethrowen because of api mismatch. With no python code in between.)

Reenable the 'extra' tests

I don't know what the reason is, but it's tripping up cffi's test suite.

Extract the logic from DEFAULT_CLASS_SIMPLE

One small change for numpy performance

merge the missing merge commits (mostly cosmetic change)

so that it can be used in more places.  Looking at pyxl_bench2_10x,
most of the calls to PyType_GenericAlloc are from the dict and list
iterator classes, which don't use DEFAULT_CLASS_SIMPLE (or DEFAULT_CLASS)
since they use the same C++ class with multiple Python classes.  So
by extracting out the core of that function, it's now usable by those
other classes.

Also convert some things to DEFAULT_CLASS_SIMPLE while we're at it.