MagicMock a pandas DataFrame causes a segfault

[roachlord]

Code Sample

import pandas as pd
from mock import MagicMock

df = pd.DataFrame(0, [[1, 2], [3, 4]], ['col'])
df['col'] += MagicMock()

Problem description

I have a function that returns a column of dataframe. I want to mock out this function and test it is called with the correct args. The above code segs outs in 0.24.1 but not in 0.23.4.

Expected Output

Not to seg fault

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 2.7.12.final.0
python-bits: 64
OS: Linux
OS-release: 4.4.0-142-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US
LOCALE: None.None

pandas: 0.24.1
pytest: None
pip: 19.0.2
setuptools: 40.8.0
Cython: None
numpy: 1.16.1
scipy: 1.2.1
pyarrow: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.8.0
pytz: 2018.9
blosc: None
bottleneck: None
tables: None
numexpr: None
feather: None
matplotlib: None
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml.etree: None
bs4: None
html5lib: None
sqlalchemy: 1.2.17
pymysql: None
psycopg2: 2.7.7 (dt dec pq3 ext lo64)
jinja2: None
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None
gcsfs: None

[gfyoung]

A very odd regression indeed, but a regression nonetheless and for a reasonable intention IMO.

[gfyoung]

cc @jreback

This stems from #24541 in which MagicMock now gets passed into pandas_dtype from when is_timedelta64_dtype is called (this function is called as well prior to this commit, but the object would not get passed to the central pandas_dtype function).

The breaking logic is here:

https://github.com/pandas-dev/pandas/blob/659e0ca/pandas/core/dtypes/common.py#L2036-L2043

Unfortunately, numpy dtypes do not play nice with MagicMock. In fact, you can replicate the segfault yourself by just doing this:

from unittest.mock import MagicMock

import numpy as np

np.dtype(MagicMock())

@roachlord : Perhaps this might be worthwhile to bring up as an issue on the numpy side as well.

[jreback]

this is not supported in any way; it may have happened to work before

[gfyoung]

@jreback : Fair enough. 👍

@roachlord : I see you are making some headway with your issue to numpy. If that gets resolved, that would also resolve the issue on our end (I think?), so perhaps that would be your best route for now.

[WillAyd]

Doesn't appear to be an issue on master so I think OK to close this one