internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pandas-dev/pandas

Issue:
DOC:  confusing wording in Dataframe.quantile 'a la'
#### Problem description
`` a la`` is confusing. The same issue I encountered in Series.quantile is in Dataframe.quantile
#21292
https://github.com/pandas-dev/pandas/blob/25e6a21ac5f3a266de97a6dc00170e106215efa1/pandas/core/frame.py#L7249-L7253
#### Expected Output

#### Output of ``pd.show_versions()``

<details>

INSTALLED VERSIONS
------------------
commit: None
python: 3.5.2.final.0
python-bits: 64
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 94 Stepping 3, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None

pandas: 0.23.4
pytest: 2.9.2
pip: 9.0.1
setuptools: 40.0.0
Cython: 0.28.4
numpy: 1.14.2
scipy: 1.0.0
pyarrow: None
xarray: None
IPython: 5.1.0
sphinx: 1.4.6
patsy: 0.4.1
dateutil: 2.6.1
pytz: 2017.3
blosc: None
bottleneck: 1.1.0
tables: 3.2.2
numexpr: 2.6.4
feather: None
matplotlib: 2.1.1
openpyxl: 2.3.2
xlrd: 1.0.0
xlwt: 1.1.2
xlsxwriter: 0.9.3
lxml: 3.6.4
bs4: 4.5.1
html5lib: None
sqlalchemy: 1.0.13
pymysql: None
psycopg2: None
jinja2: 2.8
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

</details>



Discussion:

Resolving patch:
diff --git a/pandas/core/frame.py b/pandas/core/frame.py
--- a/pandas/core/frame.py
+++ b/pandas/core/frame.py
@@ -7249,8 +7249,7 @@ def f(s):
     def quantile(self, q=0.5, axis=0, numeric_only=True,
                  interpolation='linear'):
         """
-        Return values at the given quantile over requested axis, a la
-        numpy.percentile.
+        Return values at the given quantile over requested axis.
 
         Parameters
         ----------
@@ -7315,6 +7314,7 @@ def quantile(self, q=0.5, axis=0, numeric_only=True,
         See Also
         --------
         pandas.core.window.Rolling.quantile
+        numpy.percentile
         """
         self._check_percentile(q)
 


Test patch:
Repository: pandas-dev/pandas

Issue:
loffset has no effect when passing in a numyp.timedelta64
From mailing-list: [https://groups.google.com/forum/#!topic/pydata/CDnF9cNR2ho]
When doing a re-sample, loffset has no effect if a numpy.timedelta64 is passed in:

``` python
In [1]: rng = pd.date_range('1/1/2012', periods=4, freq='S')

In [2]: ts = pd.Series(np.random.randint(0, 500, len(rng)), index=rng)

In [3]: ts.resample('2S')
Out[3]:
2012-01-01 00:00:00    396.0
2012-01-01 00:00:02    214.5
Freq: 2S, dtype: float64

In [4]: import datetime

In [5]: ts.resample('2S',loffset=datetime.timedelta(seconds=10))
Out[5]:
2012-01-01 00:00:10    396.0
2012-01-01 00:00:12    214.5
dtype: float64

In [6]: ts.resample('2S',loffset=np.timedelta64(10,'s'))
Out[6]:
2012-01-01 00:00:00    396.0
2012-01-01 00:00:02    214.5
Freq: 2S, dtype: float64
```



Discussion:
would welcome a pull-request for this
also should raise on an invalid loffset

this is already fixed in master, nice to enhance the tests.

Resolving patch:
diff --git a/pandas/core/resample.py b/pandas/core/resample.py
--- a/pandas/core/resample.py
+++ b/pandas/core/resample.py
@@ -366,7 +366,8 @@ def _apply_loffset(self, result):
         """
 
         needs_offset = (
-            isinstance(self.loffset, (DateOffset, timedelta)) and
+            isinstance(self.loffset, (DateOffset, timedelta,
+                                      np.timedelta64)) and
             isinstance(result.index, DatetimeIndex) and
             len(result.index) > 0
         )


Test patch:
diff --git a/pandas/tests/test_resample.py b/pandas/tests/test_resample.py
--- a/pandas/tests/test_resample.py
+++ b/pandas/tests/test_resample.py
@@ -1173,27 +1173,20 @@ def test_resample_frame_basic(self):
         df.resample('M', kind='period').mean()
         df.resample('W-WED', kind='period').mean()
 
-    def test_resample_loffset(self):
+    @pytest.mark.parametrize('loffset', [timedelta(minutes=1),
+                                         '1min', Minute(1),
+                                         np.timedelta64(1, 'm')])
+    def test_resample_loffset(self, loffset):
+        # GH 7687
         rng = date_range('1/1/2000 00:00:00', '1/1/2000 00:13:00', freq='min')
         s = Series(np.random.randn(14), index=rng)
 
         result = s.resample('5min', closed='right', label='right',
-                            loffset=timedelta(minutes=1)).mean()
+                            loffset=loffset).mean()
         idx = date_range('1/1/2000', periods=4, freq='5min')
         expected = Series([s[0], s[1:6].mean(), s[6:11].mean(), s[11:].mean()],
                           index=idx + timedelta(minutes=1))
         assert_series_equal(result, expected)
-
-        expected = s.resample(
-            '5min', closed='right', label='right',
-            loffset='1min').mean()
-        assert_series_equal(result, expected)
-
-        expected = s.resample(
-            '5min', closed='right', label='right',
-            loffset=Minute(1)).mean()
-        assert_series_equal(result, expected)
-
         assert result.index.freq == Minute(5)
 
         # from daily
Repository: pandas-dev/pandas

Issue:
Make Series.shift always a copy?
Right now, `Series.shift(0)` will just return the series. Shifting for all other periods induces a copy:

```python
In [1]: import pandas as pd

In [2]: a = pd.Series([1, 2])

In [3]: a.shift(1) is a
Out[3]: False

In [4]: a.shift(0) is a
Out[4]: True
```

Should we defensively copy on `0` as well, for a consistent user experience?

https://github.com/pandas-dev/pandas/blob/e669fae0762d901e61f7af84fc3b5181848d257d/pandas/core/generic.py#L8084-L8086
Make Series.shift always a copy?
Right now, `Series.shift(0)` will just return the series. Shifting for all other periods induces a copy:

```python
In [1]: import pandas as pd

In [2]: a = pd.Series([1, 2])

In [3]: a.shift(1) is a
Out[3]: False

In [4]: a.shift(0) is a
Out[4]: True
```

Should we defensively copy on `0` as well, for a consistent user experience?

https://github.com/pandas-dev/pandas/blob/e669fae0762d901e61f7af84fc3b5181848d257d/pandas/core/generic.py#L8084-L8086


Discussion:

Resolving patch:
diff --git a/pandas/core/arrays/datetimelike.py b/pandas/core/arrays/datetimelike.py
--- a/pandas/core/arrays/datetimelike.py
+++ b/pandas/core/arrays/datetimelike.py
@@ -548,7 +548,7 @@ def shift(self, n, freq=None):
 
         if n == 0:
             # immutable so OK
-            return self
+            return self.copy()
 
         if self.freq is None:
             raise NullFrequencyError("Cannot shift with no freq")
diff --git a/pandas/core/generic.py b/pandas/core/generic.py
--- a/pandas/core/generic.py
+++ b/pandas/core/generic.py
@@ -8282,7 +8282,7 @@ def mask(self, cond, other=np.nan, inplace=False, axis=None, level=None,
     @Appender(_shared_docs['shift'] % _shared_doc_kwargs)
     def shift(self, periods=1, freq=None, axis=0):
         if periods == 0:
-            return self
+            return self.copy()
 
         block_axis = self._get_block_manager_axis(axis)
         if freq is None:


Test patch:
diff --git a/pandas/tests/generic/test_series.py b/pandas/tests/generic/test_series.py
--- a/pandas/tests/generic/test_series.py
+++ b/pandas/tests/generic/test_series.py
@@ -227,3 +227,22 @@ def test_valid_deprecated(self):
         # GH18800
         with tm.assert_produces_warning(FutureWarning):
             pd.Series([]).valid()
+
+    @pytest.mark.parametrize("s", [
+        Series([np.arange(5)]),
+        pd.date_range('1/1/2011', periods=24, freq='H'),
+        pd.Series(range(5), index=pd.date_range("2017", periods=5))
+    ])
+    @pytest.mark.parametrize("shift_size", [0, 1, 2])
+    def test_shift_always_copy(self, s, shift_size):
+        # GH22397
+        assert s.shift(shift_size) is not s
+
+    @pytest.mark.parametrize("move_by_freq", [
+        pd.Timedelta('1D'),
+        pd.Timedelta('1M'),
+    ])
+    def test_datetime_shift_always_copy(self, move_by_freq):
+        # GH22397
+        s = pd.Series(range(5), index=pd.date_range("2017", periods=5))
+        assert s.shift(freq=move_by_freq) is not s
Repository: pandas-dev/pandas

Issue:
TST: remove skip for pytables build issue on numpy 1.15



Discussion:
The root cause is that https://github.com/numpy/numpy/issues/11656

```python
import pickle
import numpy as np
pickle.dumps(np.datetime64('2016-01-01T00:00:00.000000000'))
```

that just surfaced in the pytables test, since it needs to serialize the datetime64.
NumPy 1.15.1 is out, and should include this fix.

Updating https://github.com/pandas-dev/pandas/blob/68273a7a8b05049b311ea207f78e6d6f30c6eaf5/pandas/tests/io/test_pytables.py#L2194-L2197 to skip if and only if the NumPy version is exactly 1.15.0 will make for a good first contribution.

Resolving patch:
diff --git a/pandas/compat/numpy/__init__.py b/pandas/compat/numpy/__init__.py
--- a/pandas/compat/numpy/__init__.py
+++ b/pandas/compat/numpy/__init__.py
@@ -16,6 +16,7 @@
 _np_version_under1p14 = _nlv < LooseVersion('1.14')
 _np_version_under1p15 = _nlv < LooseVersion('1.15')
 
+
 if _nlv < '1.9':
     raise ImportError('this version of pandas is incompatible with '
                       'numpy < 1.9.0\n'


Test patch:
diff --git a/pandas/tests/io/test_pytables.py b/pandas/tests/io/test_pytables.py
--- a/pandas/tests/io/test_pytables.py
+++ b/pandas/tests/io/test_pytables.py
@@ -14,7 +14,7 @@
 from pandas import (Series, DataFrame, Panel, MultiIndex, Int64Index,
                     RangeIndex, Categorical, bdate_range,
                     date_range, timedelta_range, Index, DatetimeIndex,
-                    isna, compat, concat, Timestamp, _np_version_under1p15)
+                    isna, compat, concat, Timestamp)
 
 import pandas.util.testing as tm
 import pandas.util._test_decorators as td
@@ -2192,9 +2192,9 @@ def test_unimplemented_dtypes_table_columns(self):
             pytest.raises(TypeError, store.append, 'df_unimplemented', df)
 
     @pytest.mark.skipif(
-        not _np_version_under1p15,
-        reason=("pytables conda build package needs build "
-                "with numpy 1.15: gh-22098"))
+        LooseVersion(np.__version__) == LooseVersion('1.15.0'),
+        reason=("Skipping  pytables test when numpy version is "
+                "exactly equal to 1.15.0: gh-22098"))
     def test_calendar_roundtrip_issue(self):
 
         # 8591
Repository: pandas-dev/pandas

Issue:
Set hypothesis HealthCheck
from https://github.com/pandas-dev/pandas/pull/22280#issuecomment-416407165

```
# add to pandas/conftest.py
from hypothesis import settings, HealthCheck

settings.default.suppress_health_check = (HealthCheck.TooSlow,)
                                       # HealthCheck.all() to disable all health checks
```


Discussion:

Resolving patch:
diff --git a/pandas/conftest.py b/pandas/conftest.py
--- a/pandas/conftest.py
+++ b/pandas/conftest.py
@@ -9,6 +9,11 @@
 from pandas.compat import PY3
 import pandas.util._test_decorators as td
 
+import hypothesis
+hypothesis.settings.suppress_health_check = (hypothesis.HealthCheck.too_slow,)
+# HealthCheck.all() to disable all health checks
+# https://hypothesis.readthedocs.io/en/latest/healthchecks.html
+
 
 def pytest_addoption(parser):
     parser.addoption("--skip-slow", action="store_true",


Test patch:
Repository: pandas-dev/pandas

Issue:
read_sas does not handle numeric variables stored with fewer than 8 bytes in SAS datasets
This problem has been reported twice on stackoverflow, but I cannot find any issue raised here to address it.

https://stackoverflow.com/questions/49059421/pandas-fails-with-correct-data-type-while-reading-a-sas-file
https://stackoverflow.com/questions/51005244/how-can-i-preserve-the-data-type-of-a-column-when-using-pandas-read-sas/51005427#51005427

read_sas() is not handling SAS numeric values that are stored using fewer than the full 8 bytes required for floating point numbers.  It appears that instead of padding the short values with binary zeros that read_sas is using some other, perhaps randomly chosen, bytes to fill out the values.

In the first stackover flow example you can see that SAS has stored the value of the number 8.  This would be represented in IEEE floating point as the 8 bytes represented by the hex string '40 20 00 00 00 00 00 00'.  In the sas7bdat file SAS stored only the 3 most significant bytes.  Instead of padding it with 5 bytes of zeros before converting it it looks like read_sas padded it with bytes represented by the hex codes '06 07 80 FD C1' instead.  So that instead of reading the value as 8 it was read as 8.00046 .



Discussion:
cc @jreback 

Resolving patch:
diff --git a/pandas/io/sas/sas7bdat.py b/pandas/io/sas/sas7bdat.py
--- a/pandas/io/sas/sas7bdat.py
+++ b/pandas/io/sas/sas7bdat.py
@@ -614,7 +614,7 @@ def read(self, nrows=None):
         ns = (self.column_types == b's').sum()
 
         self._string_chunk = np.empty((ns, nrows), dtype=np.object)
-        self._byte_chunk = np.empty((nd, 8 * nrows), dtype=np.uint8)
+        self._byte_chunk = np.zeros((nd, 8 * nrows), dtype=np.uint8)
 
         self._current_row_in_chunk_index = 0
         p = Parser(self)


Test patch:
diff --git a/pandas/tests/io/sas/data/cars.sas7bdat b/pandas/tests/io/sas/data/cars.sas7bdat
new file mode 100644
Binary files /dev/null and b/pandas/tests/io/sas/data/cars.sas7bdat differ
diff --git a/pandas/tests/io/sas/test_sas7bdat.py b/pandas/tests/io/sas/test_sas7bdat.py
--- a/pandas/tests/io/sas/test_sas7bdat.py
+++ b/pandas/tests/io/sas/test_sas7bdat.py
@@ -183,6 +183,22 @@ def test_date_time(datapath):
     tm.assert_frame_equal(df, df0)
 
 
+def test_compact_numerical_values(datapath):
+    # Regression test for #21616
+    fname = datapath("io", "sas", "data", "cars.sas7bdat")
+    df = pd.read_sas(fname, encoding='latin-1')
+    # The two columns CYL and WGT in cars.sas7bdat have column
+    # width < 8 and only contain integral values.
+    # Test that pandas doesn't corrupt the numbers by adding
+    # decimals.
+    result = df['WGT']
+    expected = df['WGT'].round()
+    tm.assert_series_equal(result, expected, check_exact=True)
+    result = df['CYL']
+    expected = df['CYL'].round()
+    tm.assert_series_equal(result, expected, check_exact=True)
+
+
 def test_zero_variables(datapath):
     # Check if the SAS file has zero variables (PR #18184)
     fname = datapath("io", "sas", "data", "zero_variables.sas7bdat")
Repository: pandas-dev/pandas

Issue:
Change in behavior of DatetimeIndex + Offset
```python
import pandas as pd

offset = pd.tseries.offsets.Week(weekday=6)
idx = pd.DatetimeIndex(['1999-12-26', '2000-05-14']) 

assert (idx[0] + offset) == (idx + offset)[0]
```

bisected to https://github.com/pandas-dev/pandas/pull/18952

Before that the assertion was true, after it's false

```
# before
>>> idx + offset
DatetimeIndex(['2000-01-02', '2000-05-21'], dtype='datetime64[ns]', freq=None)

# after
>>> idx + offset
DatetimeIndex(['1999-12-26', '2000-05-14'], dtype='datetime64[ns]', freq=None)
```

cc @reidy-p is this an expected change due to #18952, or a new bug? If it's intentional, we should document that.


Discussion:
Hmm if I had to guess, https://github.com/pandas-dev/pandas/pull/18952/files#diff-63e1050a658278e30a3e7a744c4d6435R1324 is the line directly to blame, which seems pretty intentional :)
@TomAugspurger thanks for spotting this. It seems like the problem is a bit deeper than the line you're pointing to - I'll take a closer look and see if I can fix it.
Fails for me on master.

```python

In [1]: import pandas as pd
   ...:
   ...: offset = pd.tseries.offsets.Week(weekday=6)
   ...: idx = pd.DatetimeIndex(['1999-12-26', '2000-05-14'])
   ...:
   ...: assert (idx[0] + offset) == (idx + offset)[0]
   ...:
   ...:
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-1-8c110b991a5b> in <module>()
      4 idx = pd.DatetimeIndex(['1999-12-26', '2000-05-14'])
      5
----> 6 assert (idx[0] + offset) == (idx + offset)[0]

AssertionError:


```

are your C-extensions up to date?
@TomAugspurger Sorry that was a mistake on my part. Forgot that I had made some changes that I didn't stash before testing.

Resolving patch:
diff --git a/pandas/tseries/offsets.py b/pandas/tseries/offsets.py
--- a/pandas/tseries/offsets.py
+++ b/pandas/tseries/offsets.py
@@ -1313,7 +1313,7 @@ def _end_apply_index(self, dtindex):
         base_period = dtindex.to_period(base)
         if self.n > 0:
             # when adding, dates on end roll to next
-            normed = dtindex - off
+            normed = dtindex - off + Timedelta(1, 'D') - Timedelta(1, 'ns')
             roll = np.where(base_period.to_timestamp(how='end') == normed,
                             self.n, self.n - 1)
         else:


Test patch:
diff --git a/pandas/tests/arithmetic/test_datetime64.py b/pandas/tests/arithmetic/test_datetime64.py
--- a/pandas/tests/arithmetic/test_datetime64.py
+++ b/pandas/tests/arithmetic/test_datetime64.py
@@ -1764,6 +1764,7 @@ def test_dt64_with_DateOffsets_relativedelta(klass):
     'MonthBegin', 'MonthEnd',
     'SemiMonthEnd', 'SemiMonthBegin',
     'Week', ('Week', {'weekday': 3}),
+    'Week', ('Week', {'weekday': 6}),
     'BusinessDay', 'BDay', 'QuarterEnd', 'QuarterBegin',
     'CustomBusinessDay', 'CDay', 'CBMonthEnd',
     'CBMonthBegin', 'BMonthBegin', 'BMonthEnd',
Repository: pandas-dev/pandas

Issue:
Allow writing to GCS paths
This is quite a bit simpler than #8508 since `gcsfs` allows for writing text-type blobs so I think it makes sense to track separately.

See https://github.com/pandas-dev/pandas/issues/8508#issuecomment-421184687 for additional context.


Discussion:

Resolving patch:
diff --git a/pandas/io/formats/csvs.py b/pandas/io/formats/csvs.py
--- a/pandas/io/formats/csvs.py
+++ b/pandas/io/formats/csvs.py
@@ -22,10 +22,9 @@
     ABCMultiIndex, ABCPeriodIndex, ABCDatetimeIndex, ABCIndexClass)
 
 from pandas.io.common import (
-    _expand_user,
     _get_handle,
     _infer_compression,
-    _stringify_path,
+    get_filepath_or_buffer,
     UnicodeWriter,
 )
 
@@ -45,7 +44,9 @@ def __init__(self, obj, path_or_buf=None, sep=",", na_rep='',
         if path_or_buf is None:
             path_or_buf = StringIO()
 
-        self.path_or_buf = _expand_user(_stringify_path(path_or_buf))
+        self.path_or_buf, _, _, _ = get_filepath_or_buffer(
+            path_or_buf, encoding=encoding, compression=compression, mode=mode
+        )
         self.sep = sep
         self.na_rep = na_rep
         self.float_format = float_format


Test patch:
diff --git a/pandas/tests/io/test_gcs.py b/pandas/tests/io/test_gcs.py
--- a/pandas/tests/io/test_gcs.py
+++ b/pandas/tests/io/test_gcs.py
@@ -26,6 +26,21 @@ def test_read_csv_gcs(mock):
     assert_frame_equal(df1, df2)
 
 
+@td.skip_if_no('gcsfs')
+def test_to_csv_gcs(mock):
+    df1 = DataFrame({'int': [1, 3], 'float': [2.0, np.nan], 'str': ['t', 's'],
+                     'dt': date_range('2018-06-18', periods=2)})
+    with mock.patch('gcsfs.GCSFileSystem') as MockFileSystem:
+        s = StringIO()
+        instance = MockFileSystem.return_value
+        instance.open.return_value = s
+
+        df1.to_csv('gs://test/test.csv', index=True)
+        df2 = read_csv(StringIO(s.getvalue()), parse_dates=['dt'], index_col=0)
+
+    assert_frame_equal(df1, df2)
+
+
 @td.skip_if_no('gcsfs')
 def test_gcs_get_filepath_or_buffer(mock):
     df1 = DataFrame({'int': [1, 3], 'float': [2.0, np.nan], 'str': ['t', 's'],
Repository: pandas-dev/pandas

Issue:
access git revision of currently running pandas
I would like to know from inside the code which pandas git revision I am running at the moment. So I can easily confirm I am on proper branch/revision when testing some new features/bug fixes.
Is it possible in pandas? If it isn't I would like this issue to be FR for such functionality. Just git commit hash is enough.
In dask you can access this info with `dask.__git_revision__`.


Discussion:
I'm not very clear on the use case here - can you provide a concrete example of how this would be useful?
most common:

> easily confirm I am on proper branch/revision when testing some new features/bug fixes

more complex would be to process pipelines using different versions of pandas simultaneously, so auditing git revision from each job in a pipeline.
Pandas development version already gives an abbreviated form of the git revision:

```
In [1]: pd.__version__
Out[1]: '0.24.0.dev0+54.g10aab3c'
```

That's not sufficient?
It is good but not sufficient. It still requires lookup to git repo to get commit sha.
@jangorecki feel free to make a PR like https://github.com/dask/dask/pull/1760/files
@jangorecki could you make a PR implementing this?
@TomAugspurger not anytime soon
Added `pd.__git_version__` to reflect git sha commit version.
@atulagrwl any reason why this was not yet merged?
@jangorecki the PR is still open, and currently has a merge conflict.

Resolving patch:
diff --git a/pandas/__init__.py b/pandas/__init__.py
--- a/pandas/__init__.py
+++ b/pandas/__init__.py
@@ -83,6 +83,7 @@
 from ._version import get_versions
 v = get_versions()
 __version__ = v.get('closest-tag', v['version'])
+__git_version__ = v.get('full-revisionid')
 del get_versions, v
 
 # module level doc-string


Test patch:
diff --git a/pandas/tests/test_common.py b/pandas/tests/test_common.py
--- a/pandas/tests/test_common.py
+++ b/pandas/tests/test_common.py
@@ -1,11 +1,13 @@
 # -*- coding: utf-8 -*-
 
 import collections
+import string
 from functools import partial
 
 import numpy as np
 import pytest
 
+import pandas as pd
 from pandas import Series, Timestamp
 from pandas.core import (
     common as com,
@@ -110,3 +112,10 @@ def test_standardize_mapping():
 
     dd = collections.defaultdict(list)
     assert isinstance(com.standardize_mapping(dd), partial)
+
+
+def test_git_version():
+    # GH 21295
+    git_version = pd.__git_version__
+    assert len(git_version) == 40
+    assert all(c in string.hexdigits for c in git_version)
Repository: pandas-dev/pandas

Issue:
BLD: parsers.pyx seems to be re-running on each commit
for some reason parsers.pyx (and the generated parsers.c) seems to be rebuilding on each commit (whether anything changed or not).

cc @gfyoung @jbrockmendel 

maybe something odd in setup.py


Discussion:
Weird...even rebuilds `parsers.pyx` when I install on the same commit several times...

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -544,8 +544,7 @@ def srcpath(name=None, suffix='.pyx', subdir='src'):
     '_libs.parsers': {
         'pyxfile': '_libs/parsers',
         'depends': ['pandas/_libs/src/parser/tokenizer.h',
-                    'pandas/_libs/src/parser/io.h',
-                    'pandas/_libs/src/numpy_helper.h'],
+                    'pandas/_libs/src/parser/io.h'],
         'sources': ['pandas/_libs/src/parser/tokenizer.c',
                     'pandas/_libs/src/parser/io.c']},
     '_libs.reduction': {


Test patch: