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

Issue:
Doc comment mistake in ifft
https://github.com/numpy/numpy/blob/master/numpy/fft/fftpack.py#L205

The indices for the pos to neg frequency overflows are wrong here. They are described correctly in http://docs.scipy.org/doc/numpy-1.10.0/reference/routines.fft.html#implementation-details

Doc comment mistake in ifft
https://github.com/numpy/numpy/blob/master/numpy/fft/fftpack.py#L205

The indices for the pos to neg frequency overflows are wrong here. They are described correctly in http://docs.scipy.org/doc/numpy-1.10.0/reference/routines.fft.html#implementation-details



Discussion:
@Phaiax, if you have a bit of time, would you mind creating a pull request to fix it? For a simple documentation fix, you can even just press on the "Edit" button (though fixing it up is not as straight forward then maybe).

Tried it, but no, I do have a proxy in my way and can't ssh or git to github.com.

And what do you mean with the "Edit" button? Cant find one even in my own fork.

AAAAh, I found it. PR is on its way.

Thanks! To make it perfect, title the PR with `DOC: short description of problem`.

@Phaiax, if you have a bit of time, would you mind creating a pull request to fix it? For a simple documentation fix, you can even just press on the "Edit" button (though fixing it up is not as straight forward then maybe).

Tried it, but no, I do have a proxy in my way and can't ssh or git to github.com.

And what do you mean with the "Edit" button? Cant find one even in my own fork.

AAAAh, I found it. PR is on its way.

Thanks! To make it perfect, title the PR with `DOC: short description of problem`.


Resolving patch:
diff --git a/numpy/fft/fftpack.py b/numpy/fft/fftpack.py
--- a/numpy/fft/fftpack.py
+++ b/numpy/fft/fftpack.py
@@ -203,10 +203,16 @@ def ifft(a, n=None, axis=-1, norm=None):
     see `numpy.fft`.
 
     The input should be ordered in the same way as is returned by `fft`,
-    i.e., ``a[0]`` should contain the zero frequency term,
-    ``a[1:n/2+1]`` should contain the positive-frequency terms, and
-    ``a[n/2+1:]`` should contain the negative-frequency terms, in order of
-    decreasingly negative frequency.  See `numpy.fft` for details.
+    i.e.,
+
+    * ``a[0]`` should contain the zero frequency term,
+    * ``a[1:n//2]`` should contain the positive-frequency terms,
+    * ``a[n//2 + 1:]`` should contain the negative-frequency terms, in
+      increasing order starting from the most negative frequency.
+
+    For an even number of input points, ``A[n//2]`` represents the sum of
+    the values at the positive and negative Nyquist frequencies, as the two
+    are aliased together. See `numpy.fft` for details.
 
     Parameters
     ----------
@@ -263,9 +269,9 @@ def ifft(a, n=None, axis=-1, norm=None):
     >>> n[40:60] = np.exp(1j*np.random.uniform(0, 2*np.pi, (20,)))
     >>> s = np.fft.ifft(n)
     >>> plt.plot(t, s.real, 'b-', t, s.imag, 'r--')
-    [<matplotlib.lines.Line2D object at 0x...>, <matplotlib.lines.Line2D object at 0x...>]
+    ...
     >>> plt.legend(('real', 'imaginary'))
-    <matplotlib.legend.Legend object at 0x...>
+    ...
     >>> plt.show()
 
     """


Test patch:
Repository: numpy/numpy

Issue:
inconsistency in np.isclose
The documentation for `np.isclose` says:

> Returns a boolean array of where `a` and `b` are equal within the given tolerance. If both `a` and `b` are scalars, returns a single boolean value.

This is true for comparing two finite scalars, a single boolean value is returned:

```
>>> np.isclose(0, 1)
False
```

However, a boolean array is returned when one or more of the scalars is non-finite:

```
>>> np.isclose(0, np.inf)
array([False], dtype=bool)
```

I would expect (from the documentation) the above to return a single boolean value, not an array. I note that both values in the last example are scalars:

```
>>> np.isscalar(0)
True
>>> np.isscalar(np.inf)
True
```



Discussion:

Resolving patch:
diff --git a/numpy/core/numeric.py b/numpy/core/numeric.py
--- a/numpy/core/numeric.py
+++ b/numpy/core/numeric.py
@@ -2467,7 +2467,11 @@ def within_tol(x, y, atol, rtol):
             # Make NaN == NaN
             both_nan = isnan(x) & isnan(y)
             cond[both_nan] = both_nan[both_nan]
-        return cond
+
+        if isscalar(a) and isscalar(b):
+            return bool(cond)
+        else:
+            return cond
 
 def array_equal(a1, a2):
     """


Test patch:
diff --git a/numpy/core/tests/test_numeric.py b/numpy/core/tests/test_numeric.py
--- a/numpy/core/tests/test_numeric.py
+++ b/numpy/core/tests/test_numeric.py
@@ -1589,7 +1589,11 @@ def tst_none_isclose(self, x, y):
 
     def tst_isclose_allclose(self, x, y):
         msg = "isclose.all() and allclose aren't same for %s and %s"
-        assert_array_equal(np.isclose(x, y).all(), np.allclose(x, y), msg % (x, y))
+        msg2 = "isclose and allclose aren't same for %s and %s"
+        if np.isscalar(x) and np.isscalar(y):
+            assert_(np.isclose(x, y) == np.allclose(x, y), msg=msg % (x, y))
+        else:
+            assert_array_equal(np.isclose(x, y).all(), np.allclose(x, y), msg % (x, y))
 
     def test_ip_all_isclose(self):
         self.setup()
@@ -1650,6 +1654,14 @@ def test_no_parameter_modification(self):
         assert_array_equal(x, np.array([np.inf, 1]))
         assert_array_equal(y, np.array([0, np.inf]))
 
+    def test_non_finite_scalar(self):
+        # GH7014, when two scalars are compared the output should also be a
+        # scalar
+        assert_(np.isclose(np.inf, -np.inf) is False)
+        assert_(np.isclose(0, np.inf) is False)
+        assert_(type(np.isclose(0, np.inf)) is bool)
+
+
 class TestStdVar(TestCase):
     def setUp(self):
         self.A = np.array([1, -1, 1, -1])
Repository: numpy/numpy

Issue:
ifft RAM requirements
Hi,

I was trying to reduce the RAM requirementes of my program and noticed that the numpy.fft.ifft function needs a lot more RAM for the computation than numpy.fft.fft. I don't understand why, as the formulas for fft and ifft are nearly the same...
My numpy version is 1.8.2.

``` python
  import numpy as np
  datain = np.ones((1000,1000,100), dtype=np.complex) # 1.6 GB allocated
  x=np.fft.fft(datain); del x # running this line takes up 3 GB of RAM
  x=np.fft.ifft(datain); del x # running this line takes up 6 GB of RAM
```

I look at the RAM consumption by executing `top -d.05 | grep ipython` in a second terminal window.



Discussion:
The division/scaling factor needed for ifft is not done in an in-place manner, so a second array the same size as the result is necessary. Note that you cannot compare the memory in a single run easily, since python will not free memory immediately in all cases.
Another performance bug is the `astype` cast, which as far as I can see in all cases will create an unnecessary copy.

@seberg `a.astype(..., copy=False)` should fix the copy problem.


Resolving patch:
diff --git a/numpy/fft/fftpack.py b/numpy/fft/fftpack.py
--- a/numpy/fft/fftpack.py
+++ b/numpy/fft/fftpack.py
@@ -183,7 +183,7 @@ def fft(a, n=None, axis=-1, norm=None):
 
     """
 
-    a = asarray(a).astype(complex)
+    a = asarray(a).astype(complex, copy=False)
     if n is None:
         n = a.shape[axis]
     output = _raw_fft(a, n, axis, fftpack.cffti, fftpack.cfftf, _fft_cache)


Test patch:
Repository: numpy/numpy

Issue:
Sample code result is wrong
http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.fmin.html#numpy.fmin



Discussion:

Resolving patch:
diff --git a/numpy/core/code_generators/ufunc_docstrings.py b/numpy/core/code_generators/ufunc_docstrings.py
--- a/numpy/core/code_generators/ufunc_docstrings.py
+++ b/numpy/core/code_generators/ufunc_docstrings.py
@@ -2393,11 +2393,11 @@ def add_newdoc(place, name, doc):
     Examples
     --------
     >>> np.fmin([2, 3, 4], [1, 5, 2])
-    array([2, 5, 4])
+    array([1, 3, 2])
 
     >>> np.fmin(np.eye(2), [0.5, 2])
-    array([[ 1. ,  2. ],
-           [ 0.5,  2. ]])
+    array([[ 0.5,  0. ],
+           [ 0. ,  1. ]])
 
     >>> np.fmin([np.nan, 0, np.nan],[0, np.nan, np.nan])
     array([  0.,   0.,  NaN])


Test patch:
Repository: numpy/numpy

Issue:
ctypeslib.ndpointer cache ineffective (Trac #1707)
_Original ticket http://projects.scipy.org/numpy/ticket/1707 on 2011-01-10 by trac user Colin Hogben, assigned to unknown._

The cache of pointer types is queried with a tuple (dtype, ndim, shape, num) but values stored with a bare dtype as key.  Thus queries always miss.



Discussion:
Attachment added by trac user Colin Hogben on 2011-01-10: [0001-Make-_pointer_type_cache-functional.patch](http://projects.scipy.org/numpy/attachment/ticket/1707/0001-Make-_pointer_type_cache-functional.patch)

Yeah, looks like a bug.

@udiboy1209: nope -- as a general rule, unless someone has said they're working on something then you can assume that it's free to grab :-). (Or even if they have, but it was more than a few weeks ago.)

@njsmith I already saw a patch submitted by Colin Hogben so I deleted my comment :P . You might wanna test and apply that patch.

@udiboy1209: if you want to turn that patch into a pull request, that would be helpful :-)

@njsmith I could do that, yeah :)


Resolving patch:
diff --git a/numpy/ctypeslib.py b/numpy/ctypeslib.py
--- a/numpy/ctypeslib.py
+++ b/numpy/ctypeslib.py
@@ -315,7 +315,7 @@ def ndpointer(dtype=None, ndim=None, shape=None, flags=None):
                   "_shape_" : shape,
                   "_ndim_" : ndim,
                   "_flags_" : num})
-    _pointer_type_cache[dtype] = klass
+    _pointer_type_cache[(dtype, shape, ndim, num)] = klass
     return klass
 
 if ctypes is not None:


Test patch:
diff --git a/numpy/tests/test_ctypeslib.py b/numpy/tests/test_ctypeslib.py
--- a/numpy/tests/test_ctypeslib.py
+++ b/numpy/tests/test_ctypeslib.py
@@ -101,6 +101,11 @@ def test_flags(self):
         self.assertTrue(p.from_param(x))
         self.assertRaises(TypeError, p.from_param, np.array([[1, 2], [3, 4]]))
 
+    def test_cache(self):
+        a1 = ndpointer(dtype=np.float64)
+        a2 = ndpointer(dtype=np.float64)
+        self.assertEqual(a1, a2)
+
 
 if __name__ == "__main__":
     run_module_suite()
Repository: numpy/numpy

Issue:
numpy irr should check whether the masked solution is empty
In the current implementation, when no solution is returned by roots, the function return np.nan. But if no real solution is returned, the function fails with an exception:

```
ValueError: attempt to get argmin of an empty sequence
```

The proposed fix is to add the following to https://github.com/numpy/numpy/blob/master/numpy/lib/financial.py#L654

```
if res.size == 0 or res[mask].size == 0:
```



Discussion:

Resolving patch:
diff --git a/numpy/lib/financial.py b/numpy/lib/financial.py
--- a/numpy/lib/financial.py
+++ b/numpy/lib/financial.py
@@ -651,7 +651,7 @@ def irr(values):
     """
     res = np.roots(values[::-1])
     mask = (res.imag == 0) & (res.real > 0)
-    if res.size == 0:
+    if not mask.any():
         return np.nan
     res = res[mask].real
     # NPV(rate) = 0 can have more than one solution so we return


Test patch:
diff --git a/numpy/lib/tests/test_financial.py b/numpy/lib/tests/test_financial.py
--- a/numpy/lib/tests/test_financial.py
+++ b/numpy/lib/tests/test_financial.py
@@ -3,7 +3,7 @@
 import numpy as np
 from numpy.testing import (
     run_module_suite, TestCase, assert_, assert_almost_equal,
-    assert_allclose
+    assert_allclose, assert_equal
     )
 
 
@@ -26,6 +26,11 @@ def test_irr(self):
         v = [-5, 10.5, 1, -8, 1]
         assert_almost_equal(np.irr(v), 0.0886, 2)
 
+        # Test that if there is no solution then np.irr returns nan
+        # Fixes gh-6744
+        v = [-1, -2, -3]
+        assert_equal(np.irr(v), np.nan)
+
     def test_pv(self):
         assert_almost_equal(np.pv(0.07, 20, 12000, 0), -127128.17, 2)
Repository: numpy/numpy

Issue:
Docs for tensordot do not render math properly
See Notes section at http://docs.scipy.org/doc/numpy-1.10.1/reference/generated/numpy.tensordot.html:

```
axes = 0 : tensor product $aotimes b$ axes = 1 : tensor dot product $acdot b$ axes = 2 : (default) tensor double contraction $a:b$
```

Probably a `:math:` missing in the rst?



Discussion:

Resolving patch:
diff --git a/numpy/core/numeric.py b/numpy/core/numeric.py
--- a/numpy/core/numeric.py
+++ b/numpy/core/numeric.py
@@ -1180,9 +1180,9 @@ def tensordot(a, b, axes=2):
     Notes
     -----
     Three common use cases are:
-        ``axes = 0`` : tensor product $a\otimes b$
-        ``axes = 1`` : tensor dot product $a\cdot b$
-        ``axes = 2`` : (default) tensor double contraction $a:b$
+        * ``axes = 0`` : tensor product :math:`a\otimes b`
+        * ``axes = 1`` : tensor dot product :math:`a\cdot b`
+        * ``axes = 2`` : (default) tensor double contraction :math:`a:b`
 
     When `axes` is integer_like, the sequence for evaluation will be: first
     the -Nth axis in `a` and 0th axis in `b`, and the -1th axis in `a` and


Test patch:
Repository: numpy/numpy

Issue:
numpy fails to install if it encounters paths with percent in them due to bad ConfigParser usage
That's a bug that was discovered first on https://github.com/pydata/numexpr/issues/217 and which breaks installation completly.

Other references that explain why RawConfigParser is needed: https://bugs.python.org/issue24086

I already have a PR which I tested and it seems that is fixing this issue.



Discussion:

Resolving patch:
diff --git a/numpy/distutils/npy_pkg_config.py b/numpy/distutils/npy_pkg_config.py
--- a/numpy/distutils/npy_pkg_config.py
+++ b/numpy/distutils/npy_pkg_config.py
@@ -5,9 +5,9 @@
 import os
 
 if sys.version_info[0] < 3:
-    from ConfigParser import SafeConfigParser, NoOptionError
+    from ConfigParser import RawConfigParser, NoOptionError
 else:
-    from configparser import ConfigParser, SafeConfigParser, NoOptionError
+    from configparser import RawConfigParser, NoOptionError
 
 __all__ = ['FormatError', 'PkgNotFound', 'LibraryInfo', 'VariableSet',
         'read_config', 'parse_flags']
@@ -259,11 +259,7 @@ def parse_config(filename, dirs=None):
     else:
         filenames = [filename]
 
-    if sys.version[:3] > '3.1':
-        # SafeConfigParser is deprecated in py-3.2 and renamed to ConfigParser
-        config = ConfigParser()
-    else:
-        config = SafeConfigParser()
+    config = RawConfigParser()
 
     n = config.read(filenames)
     if not len(n) >= 1:
diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
--- a/numpy/distutils/system_info.py
+++ b/numpy/distutils/system_info.py
@@ -128,9 +128,15 @@
 from glob import glob
 from functools import reduce
 if sys.version_info[0] < 3:
-    from ConfigParser import NoOptionError, ConfigParser
+    from ConfigParser import NoOptionError
+    from ConfigParser import RawConfigParser as ConfigParser
 else:
-    from configparser import NoOptionError, ConfigParser
+    from configparser import NoOptionError
+    from configparser import RawConfigParser as ConfigParser
+# It seems that some people are importing ConfigParser from here so is 
+# good to keep its class name. Use of RawConfigParser is needed in 
+# order to be able to load path names with percent in them, like 
+# `feature%2Fcool` which is common on git flow branch names.
 
 from distutils.errors import DistutilsError
 from distutils.dist import Distribution


Test patch:
Repository: numpy/numpy

Issue:
BUG: Regression with np.histogram for value at end point
The following simple example no longer works:

``` python
np.histogram([ 0.,  0.,  0.,  1.,  2.,  3.,  3.,  4.,  5.], bins=30, range=(-0.5, 5))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-3-7ea9ff24a0b8> in <module>()
----> 1 np.histogram([ 0.,  0.,  0.,  1.,  2.,  3.,  3.,  4.,  5.], bins=30, range=(-0.5, 5))

/Users/tom/miniconda3/envs/dev35/lib/python3.5/site-packages/numpy/lib/function_base.py in histogram(a, bins, range, normed, weights, density)
    683                 n.imag += np.bincount(indices, weights=tmp_w.imag, minlength=bins)
    684             else:
--> 685                 n += np.bincount(indices, weights=tmp_w, minlength=bins).astype(ntype)
    686 
    687         # Rename the bin edges for return.

ValueError: operands could not be broadcast together with shapes (30,) (31,) (30,) 
```

I think this is a result of https://github.com/numpy/numpy/pull/7667, and is a bug due to the 5 not being correctly identified as an end point.

cc @rkern @charris



Discussion:

Resolving patch:
diff --git a/numpy/lib/function_base.py b/numpy/lib/function_base.py
--- a/numpy/lib/function_base.py
+++ b/numpy/lib/function_base.py
@@ -667,14 +667,14 @@ def histogram(a, bins=10, range=None, normed=False, weights=None,
             # Compute the bin indices, and for values that lie exactly on mx we
             # need to subtract one
             indices = tmp_a.astype(np.intp)
-            equals_endpoint = (indices == bins)
-            indices[equals_endpoint] -= 1
+            indices[indices == bins] -= 1
 
             # The index computation is not guaranteed to give exactly
             # consistent results within ~1 ULP of the bin edges.
             decrement = tmp_a_data < bin_edges[indices]
             indices[decrement] -= 1
-            increment = (tmp_a_data >= bin_edges[indices + 1]) & ~equals_endpoint
+            # The last bin includes the right edge. The other bins do not.
+            increment = (tmp_a_data >= bin_edges[indices + 1]) & (indices != bins - 1)
             indices[increment] += 1
 
             # We now compute the histogram using bincount


Test patch:
diff --git a/numpy/lib/tests/test_function_base.py b/numpy/lib/tests/test_function_base.py
--- a/numpy/lib/tests/test_function_base.py
+++ b/numpy/lib/tests/test_function_base.py
@@ -1418,6 +1418,11 @@ def test_bin_edge_cases(self):
             self.assertGreaterEqual(x, left)
             self.assertLess(x, right)
 
+    def test_last_bin_inclusive_range(self):
+        arr = np.array([0.,  0.,  0.,  1.,  2.,  3.,  3.,  4.,  5.])
+        hist, edges = np.histogram(arr, bins=30, range=(-0.5, 5))
+        self.assertEqual(hist[-1], 1)
+
 
 class TestHistogramOptimBinNums(TestCase):
     """
Repository: numpy/numpy

Issue:
Typo in documentation of savetxt
This is just a minor typo in the [documentation](http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.savetxt.html) explaining how to specify the output format for savetxt in the case of complex numbers

> a full string specifying every real and imaginary part, e.g.
> ‘ %.4e %+.4j %.4e %+.4j %.4e %+.4j’ for 3 columns

should be

> a full string specifying every real and imaginary part, e.g.
> ‘ %.4e %+.4ej %.4e %+.4ej %.4e %+.4ej’ for 3 columns

The other format strings on this particular help page are fine, but I haven't checked whether the typo has propagated to other help pages.



Discussion:

Resolving patch:
diff --git a/numpy/lib/npyio.py b/numpy/lib/npyio.py
--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -1041,7 +1041,7 @@ def savetxt(fname, X, fmt='%.18e', delimiter=' ', newline='\n', header='',
             a) a single specifier, `fmt='%.4e'`, resulting in numbers formatted
                 like `' (%s+%sj)' % (fmt, fmt)`
             b) a full string specifying every real and imaginary part, e.g.
-                `' %.4e %+.4j %.4e %+.4j %.4e %+.4j'` for 3 columns
+                `' %.4e %+.4ej %.4e %+.4ej %.4e %+.4ej'` for 3 columns
             c) a list of specifiers, one per column - in this case, the real
                 and imaginary part must have separate specifiers,
                 e.g. `['%.3e + %.3ej', '(%.15e%+.15ej)']` for 2 columns


Test patch:
Repository: numpy/numpy

Issue:
Typo in documentation of loadtxt
This is just a minor typo in the [documentation](https://github.com/numpy/numpy/blob/v1.11.0/numpy/lib/npyio.py#L682-L966) explaining how to use the usecols parameter.

> usecols : int or sequence, optional
>         Which columns to read, with 0 being the first. For example,
>         usecols = (1,4,5) will extract the 2nd, 5th and 6th columns.
>         The default, None, results in all columns being read.
>         .. versionadded:: 1.11.0
>         Also when a single column has to be read it is possible to use
>         an integer instead of a tuple. E.g `usecols = 3` reads the
>         third column the same way as `usecols = (3,)`` would.

I believe 

> E.g `usecols = 3` reads the
>         third column the same way as `usecols = (3,)`` would.

should read

> E.g `usecols = 3` reads the
>         _fourth_ column the same way as `usecols = (3,)`` would.



Discussion:
I think you are spot on: can you make this into a PR?


Resolving patch:
diff --git a/numpy/lib/npyio.py b/numpy/lib/npyio.py
--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -751,7 +751,7 @@ def loadtxt(fname, dtype=float, comments='#', delimiter=None,
 
         Also when a single column has to be read it is possible to use
         an integer instead of a tuple. E.g ``usecols = 3`` reads the
-        third column the same way as `usecols = (3,)`` would.
+        fourth column the same way as `usecols = (3,)`` would.
 
     unpack : bool, optional
         If True, the returned array is transposed, so that arguments may be


Test patch:
Repository: numpy/numpy

Issue:
DEP: Python 3.4 deprecates the imp module.
Should have a workaround applied before then.



Discussion:
What is `imp` being used for now? Could `importlib` just be imported instead?

If you grep for `import imp` you will find about 5 uses. One kind of use is an easy fix, the other more complicated. I have an old branch making a start on this, but have at it if you want. The `importlib` module isn't a straight forward replacement and only `importlib.import_module` is available in 2.7. There is nothing in 2.6, so this is a 1.12 task.

> There is nothing in 2.6, so this is a 1.12 task.

Meaning python 2.6 support will be removed in 1.12 or something else?

Python 2.6, 3.2, & 3.3 will be dropped in 1.12.

Thanks for clarifying.


Resolving patch:
diff --git a/numpy/core/setup.py b/numpy/core/setup.py
--- a/numpy/core/setup.py
+++ b/numpy/core/setup.py
@@ -1,6 +1,5 @@
 from __future__ import division, print_function
 
-import imp
 import os
 import sys
 import pickle
diff --git a/runtests.py b/runtests.py
--- a/runtests.py
+++ b/runtests.py
@@ -60,7 +60,6 @@
 import shutil
 import subprocess
 import time
-import imp
 from argparse import ArgumentParser, REMAINDER
 
 ROOT_DIR = os.path.abspath(os.path.join(os.path.dirname(__file__)))


Test patch:
Repository: numpy/numpy

Issue:
DEP: Python 3.4 deprecates the imp module.
Should have a workaround applied before then.



Discussion:
What is `imp` being used for now? Could `importlib` just be imported instead?

If you grep for `import imp` you will find about 5 uses. One kind of use is an easy fix, the other more complicated. I have an old branch making a start on this, but have at it if you want. The `importlib` module isn't a straight forward replacement and only `importlib.import_module` is available in 2.7. There is nothing in 2.6, so this is a 1.12 task.

> There is nothing in 2.6, so this is a 1.12 task.

Meaning python 2.6 support will be removed in 1.12 or something else?

Python 2.6, 3.2, & 3.3 will be dropped in 1.12.

Thanks for clarifying.


Resolving patch:
diff --git a/numpy/core/setup.py b/numpy/core/setup.py
--- a/numpy/core/setup.py
+++ b/numpy/core/setup.py
@@ -1,6 +1,5 @@
 from __future__ import division, print_function
 
-import imp
 import os
 import sys
 import pickle
diff --git a/runtests.py b/runtests.py
--- a/runtests.py
+++ b/runtests.py
@@ -58,7 +58,6 @@
 import shutil
 import subprocess
 import time
-import imp
 from argparse import ArgumentParser, REMAINDER
 
 ROOT_DIR = os.path.abspath(os.path.join(os.path.dirname(__file__)))


Test patch: