pandas 0.13.0 tests fail against numpy 1.8.x

[juliantaylor]

several test errors of this type when run against the maintenance/1.8.x branch of numpy.

ERROR: test_qcut_specify_quantiles (pandas.tools.tests.test_tile.TestCut)
  File "hashtable.pyx", line 776, in pandas.hashtable.PyObjectHashTable.unique (pandas/hashtable.c:12071)
TypeError: unhashable type: 'numpy.ndarray'

FAIL: test_series_describe_multikey (pandas.tests.test_groupby.TestGroupBy)
    assert a == b, "%s: %r != %r" % (msg.format(a,b), a, b)
AssertionError: attr is not equal [dtype]: dtype('O') != dtype('float64')

it seems you have coded a regression of 1.8 into the tests, it is intended to fix this in numpy 1.8.1 but now that pandas relies on it makes the situation a little tricky.

see numpy/numpy#4109

How bad would it be for pandas if we release 1.8.1 with the regression fixed?

[jreback]

we test again 1.8; these are failing because of changes in 1.8 (that will actually appear in 1.8.1)?

[seberg]

I just realized, this thing also fixed what I think is a bug with structured types. Since pandas makes a lot of use for that, this part is likely what breaks pandas and the regression fix is OK. So I think we can undo the structured type fix part for 1.8.x, but it would be nice to have input/know that you are aware that there should be a change for 1.9.x in numpy here.

I will have a look at it later.

[juliantaylor]

pandas tests work with numpy 1.7.2, so there is probably something additional in that changeset that breaks it.

[seberg]

Can you try if this fixes it:

--- a/doc/sphinxext
+++ b/doc/sphinxext
@@ -1 +1 @@
-Subproject commit 447dd0b59c2fe91ca9643701036d3d04919ddc7e
+Subproject commit 447dd0b59c2fe91ca9643701036d3d04919ddc7e-dirty
diff --git a/numpy/core/src/multiarray/mapping.c b/numpy/core/src/multiarray/map
index cf03f83..d83686f 100644
--- a/numpy/core/src/multiarray/mapping.c
+++ b/numpy/core/src/multiarray/mapping.c
@@ -1129,7 +1129,7 @@ array_subscript_fromobject(PyArrayObject *self, PyObject *
                 return NULL;
             }
             PyArray_ENABLEFLAGS((PyArrayObject*)obj, NPY_ARRAY_WARN_ON_WRITE);
-            return obj;
+            return PyArray_Return(obj);
         }
     }

It should undo the non-regression part of the fix.

[juliantaylor]

no the patch does not help

Thanks for the heads-up @juliantaylor. I'm not sure what you mean by "coded a regression of 1.8 into the tests".
as our CI setup tests against 1.6.1, 1.7.1 and pypi 1.8.0 and so whatever changed broke
with all those numpy versions. That's the opposite meaning of regression as I know it.

I started looking at the damage here and found at least this change in numpy behaviour,
which off-hand seems like a bug:

# np 1.7.2
In [1]: a=np.array([1,2,3])
   ...: a[1.1]
Out[1]: 2

#1.8 tip 49cff2b
In [5]: a=np.array([1,2,3])
   ...: a[1.1]
Out[5]: array(2)

We'll be releasing 13.1 in a couple of weeks, would be nice to sync up to minimize the breakage
window if there has to be one. Talk to us.

[juliantaylor]

hm yes that is a bug
it seems to be a broken backport

with current git master unfortunately the tests just crash in:
test_combine_first_dt64 (pandas.sparse.tests.test_sparse.TestSparseSeries)
I'll check what causes that.

It's a little troublesome to sort out which tests are affected by what. If you push a fix for
that, ping me and I'll make another pass to see if there's something we're actually misusing.

[jreback]

@y-p maybe we should have the 2.7 locale build run more tests and hit numpy master (rather than change another build)?

just what I was thinking, but... we want to keep our build times short, we've put some effort into that.

@juliantaylor , we have a network location that stores wheel files of our compiled dependencies
including numpy to speedup travis builds. I'm sure numpy has a fancy CI setup of their own,
if you can put up a regularly updated git-master whl at a public http location, we can probably
move one of our builds to use that and give us both better confidence when making changes.

You'll then be able to check pandas integration easily through our new CI status page.

In fact, if numpy puts up travis-compat wheels for all it's version branches that would
be useful to pydata projects at large, compilation times on travis are a killer.

[juliantaylor]

the master failure is due to a recent np.where improvement, 10 times faster, but also apparently broken for object arrays :(
I'll see to get it fixed.

[seberg]

Jeesh... yes, subscript_simple needs to be channeled through PyArray_Return, because in some corner cases (probably exactly this one, a single non-integer but integer-like scalar) it can return a scalar array which should be converted to a scalar, too. So it needs the same stuff like fancy indexing has right now...

[cpcloud]

man numpy travis compat wheels would be friggin sweet