BUG: New numpy dev caused ci to fail

[phofl]

• I have checked that this issue has not already been reported.

---

The weekly wheel of numpy changed and caused our ci to fail

Worked:
https://github.com/pandas-dev/pandas/runs/2314968903

First failure:
https://github.com/pandas-dev/pandas/runs/2315938439

Numpy wheels:

First:
https://pypi.anaconda.org/scipy-wheels-nightly/simple/numpy/1.21.0.dev0%2B1199.g623bc1fae/numpy-1.21.0.dev0%2B1199.g623bc1fae-cp38-cp38-manylinux2010_x86_64.whl

Second:
https://pypi.anaconda.org/scipy-wheels-nightly/simple/numpy/1.21.0.dev0%2B1229.g36eb76c9d/numpy-1.21.0.dev0%2B1229.g36eb76c9d-cp38-cp38-manylinux2010_x86_64.whl

cc @simonjayhawkins is this an issue for the 1.2.4 release?

[simonjayhawkins]

cc @simonjayhawkins is this an issue for the 1.2.4 release?

maybe. i'll merge (and backport) #40850 an we'll know for sure.

[jreback]

cc @seberg is this expected?

[seberg]

Seems like a bug on first sight, I will dig into where it comes from tomorrow probably. @simonjayhawkins you don't happen to know a more minimal example of what misbehaves? (My first guess right now, is that I broke some __array_wrap__ or so logic in the ufuncs)

[phofl]

@seberg
It comes down to this:

import operator
import numpy as np

result = operator.__floordiv__(np.array([True, False, False]), True)

With the new wheel this has dtype uint8 while we got int8 previously.

[seberg]

Thanks! I was indeed barking up the wrong tree then since I had not realized it was division specific.