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

Issue:
read_csv/read_table have a prefix argument which is not respected
According to the docs, `prefix` can either be a `str` or None. If it is a string then it is used as the prefix of the column name. However, no matter what string is passed, the prefix used is 'X'.



Discussion:

Resolving patch:
diff --git a/pandas/io/parsers.py b/pandas/io/parsers.py
--- a/pandas/io/parsers.py
+++ b/pandas/io/parsers.py
@@ -972,7 +972,7 @@ def __init__(self, src, **kwds):
 
         if self.names is None:
             if self.prefix:
-                self.names = ['X%d' % i
+                self.names = ['%s%d' % (self.prefix, i)
                               for i in range(self._reader.table_width)]
             else:
                 self.names = lrange(self._reader.table_width)
@@ -1563,7 +1563,7 @@ def _infer_columns(self):
             num_original_columns = ncols
             if not names:
                 if self.prefix:
-                    columns = [['X%d' % i for i in range(ncols)]]
+                    columns = [['%s%d' % (self.prefix,i) for i in range(ncols)]]
                 else:
                     columns = [lrange(ncols)]
                 columns = self._handle_usecols(columns, columns[0])


Test patch:
diff --git a/pandas/io/tests/test_parsers.py b/pandas/io/tests/test_parsers.py
--- a/pandas/io/tests/test_parsers.py
+++ b/pandas/io/tests/test_parsers.py
@@ -968,6 +968,22 @@ def test_no_header(self):
 
         self.assert_(np.array_equal(df2.columns, names))
 
+    def test_no_header_prefix(self):
+        data = """1,2,3,4,5
+6,7,8,9,10
+11,12,13,14,15
+"""
+        df_pref = self.read_table(StringIO(data), sep=',', prefix='Field',
+                                  header=None)
+
+        expected = [[1, 2, 3, 4, 5.],
+                    [6, 7, 8, 9, 10],
+                    [11, 12, 13, 14, 15]]
+        tm.assert_almost_equal(df_pref.values, expected)
+
+        self.assert_(np.array_equal(df_pref.columns,
+                                    ['Field0', 'Field1', 'Field2', 'Field3', 'Field4']))
+
     def test_header_with_index_col(self):
         data = """foo,1,2,3
 bar,4,5,6
Repository: pandas-dev/pandas

Issue:
Empty version number, when downloading pandas as zip archive
When you download the current master as zip archive from github.com, assigning a version number fails (empty string). As a consequence, packages depending on pandas (e.g. statsmodels) will fail to build as well.
I assume, the reason is the following: The version number is determined using git, but since the downloaded archive is not a git repository, this action fails and the version number remains an empty string.

I dont't think, this should be changed, but it would be helpful, if you added a node in the installation instruction, e.g. for people intending to install pandas on a machine without internet connection (like me ;)).



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -197,26 +197,30 @@ def build_extensions(self):
 
 FULLVERSION = VERSION
 if not ISRELEASED:
+    import subprocess
     FULLVERSION += '.dev'
-    try:
-        import subprocess
+
+    for cmd in ['git','git.cmd']:
         try:
-            pipe = subprocess.Popen(["git", "describe", "--always"],
-                                    stdout=subprocess.PIPE).stdout
-        except OSError:
-            # msysgit compatibility
-            pipe = subprocess.Popen(
-                ["git.cmd", "describe", "--always"],
-                stdout=subprocess.PIPE).stdout
-        rev = pipe.read().strip()
-        # makes distutils blow up on Python 2.7
-        if sys.version_info[0] >= 3:
-            rev = rev.decode('ascii')
-
-        FULLVERSION = rev.lstrip('v')
-
-    except:
-        warnings.warn("WARNING: Couldn't get git revision")
+            pipe = subprocess.Popen([cmd, "describe", "--always"],
+                                stdout=subprocess.PIPE)
+            (so,serr) = pipe.communicate()
+            if pipe.returncode == 0:
+                break
+        except:
+            pass
+
+    if pipe.returncode != 0:
+      warnings.warn("WARNING: Couldn't get git revision, using generic version string")
+    else:
+      rev = so.strip()
+      # makes distutils blow up on Python 2.7
+      if sys.version_info[0] >= 3:
+          rev = rev.decode('ascii')
+
+      # use result og git describe as version string
+      FULLVERSION = rev.lstrip('v')
+
 else:
     FULLVERSION += QUALIFIER
 


Test patch:
Repository: pandas-dev/pandas

Issue:
Assign a default value for display max_seq_items
Perhaps I've opened a dupe issue in the past, can't find it.
`pd.options.display.max_seq_items` should not be None by default.
It's easy to hang the terminal by repr()ing with some mal-chosen data.
#3426



Discussion:
I set mine to 10 by default but that may be too small. 

@jreback , @cpcloud , 0.12?

up2u

i could take care of this in the pr i have for repring large sequences but i don't think i'm going to be able to finish it by 0.12...

please do. if it doesn't make it, no problem.

@cpcloud 0.13 or push?

0.13

I kinda wish we could add defaults to config options (i.e., if I'm not defined, use this other config option instead), then we could have this default to max_rows.  Does add some complexit.

is this the _same_ as `max_rows`? (or is this applicable for something else?)

no this is different

this for repring large sequences (in general, MultiIjndex, Index, lists, dicts, etc)

max rows is for a frame summary

what's the problem with None? then its computed right?

no ... it's unlimited if it's None, so a huge index will take forever to repr

ahh...I see...why don't we just put a sensible value as th edefault, maybe 100?

I don't have this set as a matter of fact...and the unlimited is annoying

yep  that's what i've done (pr is up , but i haven't touched it in a while)... there's a tiny issue with using this with `max_edge_items` .. i'll get it ready for 0.13

gr8

@cpcloud this and max_edge_items?

@cpcloud push? 

@cpcloud ?


Resolving patch:
diff --git a/pandas/core/config_init.py b/pandas/core/config_init.py
--- a/pandas/core/config_init.py
+++ b/pandas/core/config_init.py
@@ -246,7 +246,7 @@ def mpl_style_cb(key):
                        validator=is_text)
     cf.register_option('expand_frame_repr', True, pc_expand_repr_doc)
     cf.register_option('chop_threshold', None, pc_chop_threshold_doc)
-    cf.register_option('max_seq_items', None, pc_max_seq_items)
+    cf.register_option('max_seq_items', 100, pc_max_seq_items)
     cf.register_option('mpl_style', None, pc_mpl_style_doc,
                        validator=is_one_of_factory([None, False, 'default']),
                        cb=mpl_style_cb)


Test patch:
diff --git a/pandas/tests/test_format.py b/pandas/tests/test_format.py
--- a/pandas/tests/test_format.py
+++ b/pandas/tests/test_format.py
@@ -141,9 +141,8 @@ def test_repr_chop_threshold(self):
     def test_repr_obeys_max_seq_limit(self):
         import pandas.core.common as com
 
-        #unlimited
-        reset_option("display.max_seq_items")
-        self.assertTrue(len(com.pprint_thing(lrange(1000)))> 2000)
+        with option_context("display.max_seq_items",2000):
+            self.assertTrue(len(com.pprint_thing(lrange(1000))) > 1000)
 
         with option_context("display.max_seq_items",5):
             self.assertTrue(len(com.pprint_thing(lrange(1000)))< 100)
Repository: pandas-dev/pandas

Issue:
Cannot increment after loc indexing
``` python
import pandas as pd
a = pd.Series(index=[4,5,6], data=0)
print a.loc[4:5]
a.loc[4:5] += 1
```

Yields:

```
4    0
5    0
Traceback (most recent call last):
  File "temp1.py", line 9, in <module>
dtype: int64
    a.loc[4:5] += 1
  File "lib\site-packages\pandas\core\indexing.py", line 88, in __setitem__
    self._setitem_with_indexer(indexer, value)
  File "lib\site-packages\pandas\core\indexing.py", line 177, in _setitem_with_indexer
    value = self._align_series(indexer, value)
  File "lib\site-packages\pandas\core\indexing.py", line 206, in _align_series
    raise ValueError('Incompatible indexer with Series')
ValueError: Incompatible indexer with Series
```



Discussion:

Resolving patch:
diff --git a/pandas/core/indexing.py b/pandas/core/indexing.py
--- a/pandas/core/indexing.py
+++ b/pandas/core/indexing.py
@@ -420,7 +420,10 @@ def can_do_equal_len():
             self.obj._maybe_update_cacher(clear=True)
 
     def _align_series(self, indexer, ser):
-        # indexer to assign Series can be tuple or scalar
+        # indexer to assign Series can be tuple, slice, scalar
+        if isinstance(indexer, slice):
+            indexer = tuple([indexer])
+
         if isinstance(indexer, tuple):
 
             aligners = [not _is_null_slice(idx) for idx in indexer]


Test patch:
diff --git a/pandas/tests/test_indexing.py b/pandas/tests/test_indexing.py
--- a/pandas/tests/test_indexing.py
+++ b/pandas/tests/test_indexing.py
@@ -456,6 +456,20 @@ def test_iloc_setitem(self):
         result = df.iloc[:,2:3]
         assert_frame_equal(result, expected)
 
+        # GH5771
+        s = Series(0,index=[4,5,6])
+        s.iloc[1:2] += 1
+        expected = Series([0,1,0],index=[4,5,6])
+        assert_series_equal(s, expected)
+
+    def test_loc_setitem(self):
+        # GH 5771
+        # loc with slice and series
+        s = Series(0,index=[4,5,6])
+        s.loc[4:5] += 1
+        expected = Series([1,1,0],index=[4,5,6])
+        assert_series_equal(s, expected)
+
     def test_loc_getitem_int(self):
 
         # int label
Repository: pandas-dev/pandas

Issue:
BUG: datetime with datetime ops very slow
```
In [1]: df = pd.DataFrame({ 'date1' : pd.Timestamp('20130101'), 'date2' : pd.date_range('20120101',periods=1000000,freq='s') })

In [2]: %timeit df['date1']-df['date2']
1 loops, best of 3: 2.17 s per loop
```

pretty easy fix; don't need to infer if its a series (as we know its dtype already)

should be more like this

```
In [3]: %timeit Series(df['date1'].astype('int64')-df['date2'].astype('int64'),dtype='m8[ns]')
10 loops, best of 3: 43 ms per loop
```



Discussion:

Resolving patch:
diff --git a/vb_suite/binary_ops.py b/vb_suite/binary_ops.py
--- a/vb_suite/binary_ops.py
+++ b/vb_suite/binary_ops.py
@@ -103,6 +103,9 @@
     Benchmark("df[(df>0) & (df2>0)]", setup, name='frame_multi_and_no_ne',cleanup="expr.set_use_numexpr(True)",
               start_date=datetime(2013, 2, 26))
 
+#----------------------------------------------------------------------
+# timeseries
+
 setup = common_setup + """
 N = 1000000
 halfway = N // 2 - 1
@@ -114,3 +117,13 @@
                                      start_date=datetime(2013, 9, 27))
 series_timestamp_compare = Benchmark("s <= ts", setup,
                                      start_date=datetime(2012, 2, 21))
+
+setup = common_setup + """
+N = 1000000
+s = Series(date_range('20010101', periods=N, freq='s'))
+"""
+
+timestamp_ops_diff1 = Benchmark("s.diff()", setup,
+                                start_date=datetime(2013, 1, 1))
+timestamp_ops_diff2 = Benchmark("s-s.shift()", setup,
+                                start_date=datetime(2013, 1, 1))


Test patch:
Repository: pandas-dev/pandas

Issue:
python3.2 difficulty to use pre-generated pandas/msgpack.cpp
on all aged Debian/Ubuntus (e.g. wheeze) where I build using pre-cythonized sources python3.2 seems to become blind and tries only to look for msgpack.c, not msgpack.cpp:

```
~/pandas-0.13.0# python3.2 setup.py build_ext
running build_ext
Traceback (most recent call last):
  File "setup.py", line 583, in <module>
    **setuptools_kwargs)
  File "/usr/lib/python3.2/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.2/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.2/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.2/distutils/command/build_ext.py", line 344, in run
    self.build_extensions()
  File "setup.py", line 346, in build_extensions
    self.check_cython_extensions(self.extensions)
  File "setup.py", line 343, in check_cython_extensions
    """ % src)
Exception: Cython-generated file 'pandas/msgpack.c' not found.
                Cython is required to compile pandas from a development branch.
                Please install Cython or download a release package of pandas.

~/pandas-0.13.0# ls -l pandas/msgpack.cpp 
-rw-r--r-- 1 pbuilder pbuilder 570047 Jan  3 03:44 pandas/msgpack.cpp
```

I wonder if anyone ran into this misbehavior (before I start patching left and right ;-) )



Discussion:
this has a specific entry in setup.py to check for the cpp, but @wesm would know more

your line numbers are different that what I see in current master. is this a current setup.py file?

this one I believe is just a symptom of borken setuptools or distutils with python3.2

there were changes in setup.py after 0.13.0 release that is why line numbers might be different?

@yarikoptic sorry..was some slight changes (in formatting)

can you work around this? 

I've never had to deal with this myself. 


Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -486,7 +486,8 @@ def pxd(name):
 
 msgpack_ext = Extension('pandas.msgpack',
                         sources = [srcpath('msgpack',
-                                           suffix=suffix, subdir='')],
+                                   suffix=suffix if suffix == '.pyx' else '.cpp',
+                                   subdir='')],
                         language='c++',
                         include_dirs=common_include,
                         define_macros=macros)
@@ -499,7 +500,7 @@ def pxd(name):
 if suffix == '.pyx' and 'setuptools' in sys.modules:
     # undo dumb setuptools bug clobbering .pyx sources back to .c
     for ext in extensions:
-        if ext.sources[0].endswith('.c'):
+        if ext.sources[0].endswith(('.c','.cpp')):
             root, _ = os.path.splitext(ext.sources[0])
             ext.sources[0] = root + suffix
 


Test patch:
Repository: pandas-dev/pandas

Issue:
BUG: groupby with datetime and cythonized functions regression from 0.12
```
In [30]: DataFrame(dict(A = Timestamp('20130101'), B = np.arange(5))).groupby('A')['A'].max()
Out[30]: 
A
2013-01-01    1356998400000000000
Name: A, dtype: int64
```

should match

```
In [31]: DataFrame(dict(A = Timestamp('20130101'), B = np.arange(5))).groupby('A')['A'].apply(lambda x: x.max())
Out[31]: 
A
2013-01-01   2013-01-01 00:00:00
dtype: datetime64[ns]
```



Discussion:

Resolving patch:
diff --git a/pandas/core/common.py b/pandas/core/common.py
--- a/pandas/core/common.py
+++ b/pandas/core/common.py
@@ -1102,6 +1102,14 @@ def _possibly_downcast_to_dtype(result, dtype):
                     # hit here
                     if (new_result == result).all():
                         return new_result
+
+        # a datetimelike
+        elif dtype.kind in ['M','m'] and result.dtype.kind in ['i']:
+            try:
+                result = result.astype(dtype)
+            except:
+                pass
+
     except:
         pass
 


Test patch:
diff --git a/pandas/tests/test_groupby.py b/pandas/tests/test_groupby.py
--- a/pandas/tests/test_groupby.py
+++ b/pandas/tests/test_groupby.py
@@ -2672,6 +2672,14 @@ def test_groupby_first_datetime64(self):
         got_dt = result.dtype
         self.assert_(issubclass(got_dt.type, np.datetime64))
 
+    def test_groupby_max_datetime64(self):
+        # GH 5869
+        # datetimelike dtype conversion from int
+        df = DataFrame(dict(A = Timestamp('20130101'), B = np.arange(5)))
+        expected = df.groupby('A')['A'].apply(lambda x: x.max())
+        result = df.groupby('A')['A'].max()
+        assert_series_equal(result,expected)
+
     def test_groupby_categorical_unequal_len(self):
         import pandas as pd
         #GH3011
Repository: pandas-dev/pandas

Issue:
"IndexingError: Unalignable boolean Series key provided" when passing an empty object Series
For some reason, with 0.13, an empty object Series is interpreted as a boolean one, when using to fetch elements in another Series:

```
pandas.Series(['A', 'B'])[pandas.Series([], dtype=object)]
```

The following works though, so the dtype confusion seems to be confined to empty Series:

```
pandas.Series(['A', 'B'])[pandas.Series(['C'], dtype=object)]
```



Discussion:
hmm...

the 2nd acts like a reindex, while the 1st is odd as well

marking as a bug/api issue...

what do you think they should do?

Why do you think that the 2nd is odd? Isn't it what one would expect when passing a Series, i.e. something equivalent to passing an array (using the Series' values)?
I would expect the 1st to return the same thing as what happens when passing a Series of dtype float, i.e. an empty Series. N.B: This used to work in 0.12


Resolving patch:
diff --git a/pandas/core/common.py b/pandas/core/common.py
--- a/pandas/core/common.py
+++ b/pandas/core/common.py
@@ -1660,7 +1660,7 @@ def _is_bool_indexer(key):
         if key.dtype == np.object_:
             key = np.asarray(_values_from_object(key))
 
-            if len(key) and not lib.is_bool_array(key):
+            if not lib.is_bool_array(key):
                 if isnull(key).any():
                     raise ValueError('cannot index with vector containing '
                                      'NA / NaN values')


Test patch:
diff --git a/pandas/tests/test_series.py b/pandas/tests/test_series.py
--- a/pandas/tests/test_series.py
+++ b/pandas/tests/test_series.py
@@ -16,6 +16,7 @@
 from pandas import (Index, Series, DataFrame, isnull, notnull,
                     bdate_range, date_range, _np_version_under1p7)
 from pandas.core.index import MultiIndex
+from pandas.core.indexing import IndexingError
 from pandas.tseries.index import Timestamp, DatetimeIndex
 import pandas.core.config as cf
 import pandas.lib as lib
@@ -795,6 +796,28 @@ def test_getitem_boolean_empty(self):
         self.assertEqual(s.index.name, 'index_name')
         self.assertEqual(s.dtype, np.int64)
 
+        # GH5877
+        # indexing with empty series
+        s = Series(['A', 'B'])
+        expected = Series(np.nan,index=['C'],dtype=object)
+        result = s[Series(['C'], dtype=object)]
+        assert_series_equal(result, expected)
+
+        s = Series(['A', 'B'])
+        expected = Series(dtype=object)
+        result = s[Series([], dtype=object)]
+        assert_series_equal(result, expected)
+
+        # invalid because of the boolean indexer
+        # that's empty or not-aligned
+        def f():
+            s[Series([], dtype=bool)]
+        self.assertRaises(IndexingError, f)
+
+        def f():
+            s[Series([True], dtype=bool)]
+        self.assertRaises(IndexingError, f)
+
     def test_getitem_generator(self):
         gen = (x > 0 for x in self.series)
         result = self.series[gen]
Repository: pandas-dev/pandas

Issue:
test_json:test_round_trip_exception_  fails on python3 in windows
The API design issue discussed in #5655 again. pd.read_json guesses that a 150KB long string is a filename. 

``` python

======================================================================
ERROR: test_round_trip_exception_ (pandas.io.tests.test_json.test_pandas.TestPandasContainer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\workspace\pandas_tests@2\BITS\64\PYTHONVER\33\pandas\util\testing.py", line 1057, in network_wrapper
    return t(*args, **kwargs)
  File "C:\workspace\pandas_tests@2\BITS\64\PYTHONVER\33\pandas\io\tests\test_json\test_pandas.py", line 593, in test_round_trip_exception_
    result = pd.read_json(s)
  File "C:\workspace\pandas_tests@2\BITS\64\PYTHONVER\33\pandas\io\json.py", line 176, in read_json
    if os.path.exists(filepath_or_buffer):
  File "c:\envs\33-64\lib\genericpath.py", line 18, in exists
    os.stat(path)
nose.proxy.ValueError: ValueError: path too long for Windows
-------------------- >> begin captured stdout << ---------------------
Failed: ValueError('path too long for Windows',)

--------------------- >> end captured stdout << ----------------------

```



Discussion:

Resolving patch:
diff --git a/pandas/io/json.py b/pandas/io/json.py
--- a/pandas/io/json.py
+++ b/pandas/io/json.py
@@ -173,7 +173,15 @@ def read_json(path_or_buf=None, orient=None, typ='frame', dtype=True,
 
     filepath_or_buffer, _ = get_filepath_or_buffer(path_or_buf)
     if isinstance(filepath_or_buffer, compat.string_types):
-        if os.path.exists(filepath_or_buffer):
+        try:
+            exists = os.path.exists(filepath_or_buffer)
+
+        # if the filepath is too long will raise here
+        # 5874
+        except (TypeError,ValueError):
+            exists = False
+
+        if exists:
             with open(filepath_or_buffer, 'r') as fh:
                 json = fh.read()
         else:
diff --git a/pandas/io/packers.py b/pandas/io/packers.py
--- a/pandas/io/packers.py
+++ b/pandas/io/packers.py
@@ -147,11 +147,11 @@ def read(fh):
     if isinstance(path_or_buf, compat.string_types):
 
         try:
-            path_exists = os.path.exists(path_or_buf)
-        except (TypeError):
-            path_exists = False
+            exists = os.path.exists(path_or_buf)
+        except (TypeError,ValueError):
+            exists = False
 
-        if path_exists:
+        if exists:
             with open(path_or_buf, 'rb') as fh:
                 return read(fh)
 


Test patch:
Repository: pandas-dev/pandas

Issue:
dt+BDay(n) gives the wrong date if n>5, n%5==0 and dt not on offset
This issue is closely related to bug #2680 and I believe it is also a bug.

The problem appears when adding a number of BDay n with n > 5, n % 5 == 0 to 
a starting date which is not on offset.

For instance

``` python
dt = Timestamp('20140105') # Sunday
print (dt + BDay(10)).strftime('%A')
```

```
Sunday
```

We except Friday and not Sunday. Likewise, Friday is 'gone' from the week in the following loop:

``` python
for i in range(8,12):
    print i, (Timestamp('20140104') + BDay(i)).strftime('%A')
```

```
8 Wednesday
9 Thursday
10 Saturday
11 Monday
```

It does yield the correct results for substraction however:

``` python
for i in range(9,13):
    print i, (Timestamp('20140105') - BDay(i)).strftime('%A')
```

```
9 Tuesday
10 Monday
11 Friday
12 Thursday
```

I have patched tseries/offsets.py with a couple of lines and it corrects the problem without apparently breaking any of the existing tests (version 0.13.0-94-g0bab303). I am not super familiar with git but can try to write a PR about this if appropriate.



Discussion:
a PR would be appreciated 

pls include your above examples as tests

Ok sure.


Resolving patch:
diff --git a/pandas/tseries/offsets.py b/pandas/tseries/offsets.py
--- a/pandas/tseries/offsets.py
+++ b/pandas/tseries/offsets.py
@@ -397,7 +397,9 @@ def apply(self, other):
                 if n < 0 and result.weekday() > 4:
                     n += 1
                 n -= 5 * k
-
+                if n == 0 and result.weekday() > 4:
+                    n -= 1
+            
             while n != 0:
                 k = n // abs(n)
                 result = result + timedelta(k)


Test patch:
diff --git a/pandas/tseries/tests/test_offsets.py b/pandas/tseries/tests/test_offsets.py
--- a/pandas/tseries/tests/test_offsets.py
+++ b/pandas/tseries/tests/test_offsets.py
@@ -317,6 +317,11 @@ def test_apply_large_n(self):
         rs = st + off
         xp = datetime(2011, 12, 26)
         self.assertEqual(rs, xp)
+        
+        off = BDay() * 10
+        rs = datetime(2014, 1, 5) + off # see #5890
+        xp = datetime(2014, 1, 17)
+        self.assertEqual(rs, xp)
 
     def test_apply_corner(self):
         self.assertRaises(TypeError, BDay().apply, BMonthEnd())