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

Issue:
DOC: Incorrect listing of `order` parameter in tobytes
The docstring for `tobytes` ([link to source](https://github.com/numpy/numpy/blob/e66453568b685dee47d6e6e634b3a47edffcaeed/numpy/core/_add_newdocs.py#L3935-L3969)) lists the options for the order parameter as 'C', 'F', and None but does not include 'A' or 'K' (as in e.g. the copy docstring). 'Any' is also mentioned as a (seemingly) valid input for the `order` argument in the first part of the docstring.

### Numpy/Python version information:

1.19.0.dev0+35d5c2f 3.8.2 (default, Apr  8 2020, 14:31:25) 
[GCC 9.3.0]


Discussion:
Hi, I am interested to work on this.
Please feel free to do so!
Thanks! Had a doubt. There is no 'Any' valid input for order argument, actually it meant was if no order is given: choose C as default order, unless F_CONTIGUOUS flag is set. When I try, `x.tobytes('Any')`, get an error of `Please pass in 'C', 'F', 'A', or 'K' instead`. I think the statement needs clarification, right? 
Got clarity: I think 'Any' is nothing but 'A' order.
> When I try, x.tobytes('Any'), get an error of Please pass in 'C', 'F', 'A', or 'K' instead

Correct - this is the crux of what needs clarification

Resolving patch:
diff --git a/numpy/core/_add_newdocs.py b/numpy/core/_add_newdocs.py
--- a/numpy/core/_add_newdocs.py
+++ b/numpy/core/_add_newdocs.py
@@ -1525,7 +1525,7 @@
         Controls the memory layout of the output. 'C' means it should
         be C contiguous. 'F' means it should be Fortran contiguous,
         'A' means it should be 'F' if the inputs are all 'F', 'C' otherwise.
-        'K' means it should be as close to the layout as the inputs as
+        'K' means it should be as close to the layout of the inputs as
         is possible, including arbitrarily permuted axes.
         Default is 'K'.
     casting : {'no', 'equiv', 'safe', 'same_kind', 'unsafe'}, optional
@@ -3938,18 +3938,17 @@
     Construct Python bytes containing the raw data bytes in the array.
 
     Constructs Python bytes showing a copy of the raw contents of
-    data memory. The bytes object can be produced in either 'C' or 'Fortran',
-    or 'Any' order (the default is 'C'-order). 'Any' order means C-order
-    unless the F_CONTIGUOUS flag in the array is set, in which case it
-    means 'Fortran' order.
+    data memory. The bytes object is produced in C-order by default.
+    This behavior is controlled by the ``order`` parameter.
 
     .. versionadded:: 1.9.0
 
     Parameters
     ----------
-    order : {'C', 'F', None}, optional
-        Order of the data for multidimensional arrays:
-        C, Fortran, or the same as for the original array.
+    order : {'C', 'F', 'A'}, optional
+        Controls the memory layout of the bytes object. 'C' means C-order,
+        'F' means F-order, 'A' (short for *Any*) means 'F' if `a` is
+        Fortran contiguous, 'C' otherwise. Default is 'C'.
 
     Returns
     -------


Test patch:
Repository: numpy/numpy

Issue:
Numpy failing to install with python3.5
The new release of numpy fails to install when using python3.5. It seems clear the problem is the use of f string formatting in the setup.py file that is only supported in python 3.6 and higher.

### Reproducing code example:

```
docker run python:3.5.2-alpine pip install numpy==1.19.0rc1
```

<!-- Remove these sections for a feature request -->

### Error message:

      File "/tmp/pip-build-gg798dty/numpy/setup.py", line 182
        raise ValueError(f'Submodule {p} missing')
                                                ^
    SyntaxError: invalid syntax

### Numpy/Python version information:

Fails installing `numpy==1.19.0rc1`




Discussion:
NumPy 1.19.x doesn't support Python 3.5, only 3.6-3.8
Ok, then this metadata should probably be updated: https://github.com/numpy/numpy/blob/0ea1a6e4f7904b79d26239804c1712a389f46a6b/setup.py#L448

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -443,9 +443,9 @@ def setup_package():
         license = 'BSD',
         classifiers=[_f for _f in CLASSIFIERS.split('\n') if _f],
         platforms = ["Windows", "Linux", "Solaris", "Mac OS-X", "Unix"],
-        test_suite='nose.collector',
+        test_suite='pytest',
         cmdclass=cmdclass,
-        python_requires='>=3.5',
+        python_requires='>=3.6',
         zip_safe=False,
         entry_points={
             'console_scripts': f2py_cmds


Test patch:
Repository: numpy/numpy

Issue:
np.ma.core.doc_note does not work correctly for indented docstrings
Given:
```python
class C:
    def method(self):
        """ This docstring

        Has multiple lines

        And notes

        Notes
        -----
        original note
        """
```
`np.ma.core.doc_note` gives:
```python
>>> print(np.ma.core.doc_note(Bar.foo.__doc__, "badly indented note"))
 This docstring

        Has multiple lines

        And notes

    Notes
    -----
    badly indented note

        original note
```
which has bad indents.

This isn't public API, but it's possible we're being caught out by this internally somewhere.


Discussion:

Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -21,6 +21,7 @@
 """
 # pylint: disable-msg=E1002
 import builtins
+import inspect
 import operator
 import warnings
 import textwrap
@@ -122,15 +123,8 @@ def doc_note(initialdoc, note):
     if note is None:
         return initialdoc
 
-    notesplit = re.split(r'\n\s*?Notes\n\s*?-----', initialdoc)
-
-    notedoc = """\
-Notes
-    -----
-    %s""" % note
-
-    if len(notesplit) > 1:
-        notedoc = '\n\n    ' + notedoc + '\n'
+    notesplit = re.split(r'\n\s*?Notes\n\s*?-----', inspect.cleandoc(initialdoc))
+    notedoc = "\n\nNotes\n-----\n%s\n" % inspect.cleandoc(note)
 
     return ''.join(notesplit[:1] + [notedoc] + notesplit[1:])
 


Test patch:
diff --git a/numpy/ma/tests/test_core.py b/numpy/ma/tests/test_core.py
--- a/numpy/ma/tests/test_core.py
+++ b/numpy/ma/tests/test_core.py
@@ -34,8 +34,8 @@
     MAError, MaskError, MaskType, MaskedArray, abs, absolute, add, all,
     allclose, allequal, alltrue, angle, anom, arange, arccos, arccosh, arctan2,
     arcsin, arctan, argsort, array, asarray, choose, concatenate,
-    conjugate, cos, cosh, count, default_fill_value, diag, divide, empty,
-    empty_like, equal, exp, flatten_mask, filled, fix_invalid,
+    conjugate, cos, cosh, count, default_fill_value, diag, divide, doc_note,
+    empty, empty_like, equal, exp, flatten_mask, filled, fix_invalid,
     flatten_structured_array, fromflex, getmask, getmaskarray, greater,
     greater_equal, identity, inner, isMaskedArray, less, less_equal, log,
     log10, make_mask, make_mask_descr, mask_or, masked, masked_array,
@@ -5283,3 +5283,33 @@ def test_mask_shape_assignment_does_not_break_masked():
     b = np.ma.array(1, mask=a.mask)
     b.shape = (1,)
     assert_equal(a.mask.shape, ())
+
+@pytest.mark.skipif(sys.flags.optimize > 1,
+                    reason="no docstrings present to inspect when PYTHONOPTIMIZE/Py_OptimizeFlag > 1")
+def test_doc_note():
+    def method(self):
+        """This docstring
+
+        Has multiple lines
+
+        And notes
+
+        Notes
+        -----
+        original note
+        """
+        pass
+
+    expected_doc = """This docstring
+
+Has multiple lines
+
+And notes
+
+Notes
+-----
+note
+
+original note"""
+
+    assert_equal(np.ma.core.doc_note(method.__doc__, "note"), expected_doc)
Repository: numpy/numpy

Issue:
DOC: link to SciPy's multidimensional interpolation functions
<!-- Please describe the issue in detail here, and fill in the fields below -->

### Reproducing code example:

np.interp currently requires its `fp` argument to be one-dimensional.  An obvious generalization would be to allow interpolation of `R->R^n` functions, by allowing `fp` to have shape (..., len(x)) (or (len(x), ...) -- whichever is consistent with e.g. polyfit).  Obviously the shapes of `left` and `right` should be adjusted accordingly.

Thoughts?

### Numpy/Python version information:

<!-- Output from 'import sys, numpy; print(numpy.__version__, sys.version)' -->
```
1.17.0 3.7.3 (default, Mar 27 2019, 22:11:17) 
[GCC 7.3.0]
```



Discussion:
I second this request.
It would make things a lot faster for multidimensional arrays.
Another way to accomplish this would be to save the linear operator associated with an interp(x, xp, .) function and to apply that to various sets of fp.
I agree with @mattip's change of the subject here: NumPy should not grow its interpolation functionality, but cross-link to `scipy.interpolate` in docstrings.
Adding "good first issue". Note: please use intersphinx mapping for linking, i.e. a fully-qualified name with single backticks like so:
```
`scipy.interpolate.UnivariateSpline`
```
May I try? 
@LSchroefl please go for it. No need to ask for permission, you can work on this or any topic that seems interesting to you.

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
@@ -1332,6 +1332,10 @@ def interp(x, xp, fp, left=None, right=None, period=None):
         If `xp` or `fp` are not 1-D sequences
         If `period == 0`
 
+    See Also
+    --------
+    scipy.interpolate 
+
     Notes
     -----
     The x-coordinate sequence is expected to be increasing, but this is not


Test patch:
Repository: numpy/numpy

Issue:
Uninformative error message when trying to install using python<3.6
Because `setup.py` (lines [182](https://github.com/numpy/numpy/blob/master/setup.py#L182), [191](https://github.com/numpy/numpy/blob/master/setup.py#L191)) uses f-strings introduced in python 3.6, anyone using lower version of python would get a syntax error message. The [code checking if version>=3.6](https://github.com/numpy/numpy/blob/master/setup.py#L29) and producing an informative error message for the user would not be executed.

Possible solutions include but are not limited to:
1. Putting the f-strings in try-catch block, e.g.
```
try:
    eval("raise ValueError(f'Submodule {p} missing')")
except SyntaxError:
    raise RuntimeError('Support for f-strings required')
```

2. Removing f-strings and using "traditional" string formatting methods for backward compatibility

AFAIK using `from __future__ import` would be troublesome here https://stackoverflow.com/questions/42097052/can-i-import-pythons-3-6s-formatted-string-literals-f-strings-into-older-3-x

If a decision is made to address this non-critical issue and change `setup.py` in any way, I will be glad to submit a PR.

### Reproducing code example:
e.g. `python setup.py build_ext -i`

### Error message:
```
  File "setup.py", line 182
    raise ValueError(f'Submodule {p} missing')
                                            ^
SyntaxError: invalid syntax
```


### Numpy/Python version information:
`1.16.3 3.5.2`





Discussion:
We should just remove the f-strings in this file I think

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -179,7 +179,7 @@ def check_submodules():
             if 'path' in l:
                 p = l.split('=')[-1].strip()
                 if not os.path.exists(p):
-                    raise ValueError(f'Submodule {p} missing')
+                    raise ValueError('Submodule {} missing'.format(p))
 
 
     proc = subprocess.Popen(['git', 'submodule', 'status'],
@@ -188,7 +188,7 @@ def check_submodules():
     status = status.decode("ascii", "replace")
     for line in status.splitlines():
         if line.startswith('-') or line.startswith('+'):
-            raise ValueError(f'Submodule not clean: {line}')
+            raise ValueError('Submodule not clean: {}'.format(line))
             
 
 


Test patch:
Repository: numpy/numpy

Issue:
Docs link is outdated on PyPI
https://github.com/numpy/numpy/blob/1d598997543637b9882d1663117b573210a20583/setup.py#L439

I assume we should be using a `numpy.org` link here, possibly derived from the version number?


Discussion:
I think this should be https://numpy.org/doc/stable 
I'd argue it should be pinned to the release version number, so that if someone goes to a historic pypi release, they get a link to the corresponding historic docs page.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -403,6 +403,16 @@ def parse_setuppy_commands():
     return True
 
 
+def get_docs_url():
+    if not ISRELEASED:
+        return "https://numpy.org/devdocs"
+    else:
+        # For releaeses, this URL ends up on pypi.
+        # By pinning the version, users looking at old PyPI releases can get
+        # to the associated docs easily.
+        return "https://numpy.org/doc/{}.{}".format(MAJOR, MINOR)
+
+
 def setup_package():
     src_path = os.path.dirname(os.path.abspath(__file__))
     old_path = os.getcwd()
@@ -437,7 +447,7 @@ def setup_package():
         download_url = "https://pypi.python.org/pypi/numpy",
         project_urls={
             "Bug Tracker": "https://github.com/numpy/numpy/issues",
-            "Documentation": "https://docs.scipy.org/doc/numpy/",
+            "Documentation": get_docs_url(),
             "Source Code": "https://github.com/numpy/numpy",
         },
         license = 'BSD',


Test patch:
Repository: numpy/numpy

Issue:
Improperly-formatted docstring for numpy.lib.format.descr_to_dtype
The docstring for `numpy.lib.format.descr_to_dtype` does not conform to the `numpydoc` standard. Currently the docstring is not included in the documentation generated by sphinx. 

### Numpy/Python version information:

1.20.0.dev0+e7adb14 3.8.3 (default, May 17 2020, 18:15:42) 
[GCC 10.1.0]


Discussion:
In addition to being improperly-formatted, the docstring itself is also a bit confusing and could be made more clear.

Resolving patch:
diff --git a/numpy/lib/format.py b/numpy/lib/format.py
--- a/numpy/lib/format.py
+++ b/numpy/lib/format.py
@@ -280,14 +280,26 @@ def dtype_to_descr(dtype):
         return dtype.str
 
 def descr_to_dtype(descr):
-    '''
-    descr may be stored as dtype.descr, which is a list of
-    (name, format, [shape]) tuples where format may be a str or a tuple.
-    Offsets are not explicitly saved, rather empty fields with
-    name, format == '', '|Vn' are added as padding.
-
-    This function reverses the process, eliminating the empty padding fields.
-    '''
+    """
+    Returns a dtype based off the given description.
+
+    This is essentially the reverse of `dtype_to_descr()`. It will remove
+    the valueless padding fields created by, i.e. simple fields like
+    dtype('float32'), and then convert the description to its corresponding
+    dtype.
+
+    Parameters
+    ----------
+    descr : object
+        The object retreived by dtype.descr. Can be passed to
+        `numpy.dtype()` in order to replicate the input dtype.
+
+    Returns
+    -------
+    dtype : dtype
+        The dtype constructed by the description.
+
+    """
     if isinstance(descr, str):
         # No padding removal needed
         return numpy.dtype(descr)


Test patch:
Repository: numpy/numpy

Issue:
DOC: as*array functions incorrectly describe the order kwarg
All of the functions such as `np.asanyarray`, `np.ascontiguousarray`, etc. simply forward to `np.array`, which supports `K` and `A` order. However, these do not document it correctly.

Since all of those functions use `copy=False`, the can probably just list `K` and `A` and say that the value has no effect, unless a copy has to be made (in which case they can refer to `np.array`?)


Discussion:

Resolving patch:
diff --git a/numpy/core/_asarray.py b/numpy/core/_asarray.py
--- a/numpy/core/_asarray.py
+++ b/numpy/core/_asarray.py
@@ -23,9 +23,12 @@ def asarray(a, dtype=None, order=None):
         of lists and ndarrays.
     dtype : data-type, optional
         By default, the data-type is inferred from the input data.
-    order : {'C', 'F'}, optional
-        Whether to use row-major (C-style) or
-        column-major (Fortran-style) memory representation.
+    order : {'C', 'F', 'A', 'K'}, optional
+        Memory layout.  'A' and 'K' depend on the order of input array a.
+        'C' row-major (C-style), 
+        'F' column-major (Fortran-style) memory representation.
+        'A' (any) means 'F' if `a` is Fortran contiguous, 'C' otherwise
+        'K' (keep) preserve input order
         Defaults to 'C'.
 
     Returns
@@ -95,9 +98,13 @@ def asanyarray(a, dtype=None, order=None):
         tuples of lists, and ndarrays.
     dtype : data-type, optional
         By default, the data-type is inferred from the input data.
-    order : {'C', 'F'}, optional
-        Whether to use row-major (C-style) or column-major
-        (Fortran-style) memory representation.  Defaults to 'C'.
+    order : {'C', 'F', 'A', 'K'}, optional
+        Memory layout.  'A' and 'K' depend on the order of input array a.
+        'C' row-major (C-style), 
+        'F' column-major (Fortran-style) memory representation.
+        'A' (any) means 'F' if `a` is Fortran contiguous, 'C' otherwise
+        'K' (keep) preserve input order
+        Defaults to 'C'.
 
     Returns
     -------
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
@@ -431,10 +431,13 @@ def asarray_chkfinite(a, dtype=None, order=None):
         of lists and ndarrays.  Success requires no NaNs or Infs.
     dtype : data-type, optional
         By default, the data-type is inferred from the input data.
-    order : {'C', 'F'}, optional
-         Whether to use row-major (C-style) or
-         column-major (Fortran-style) memory representation.
-         Defaults to 'C'.
+    order : {'C', 'F', 'A', 'K'}, optional
+        Memory layout.  'A' and 'K' depend on the order of input array a.
+        'C' row-major (C-style), 
+        'F' column-major (Fortran-style) memory representation.
+        'A' (any) means 'F' if `a` is Fortran contiguous, 'C' otherwise
+        'K' (keep) preserve input order
+        Defaults to 'C'.
 
     Returns
     -------


Test patch:
Repository: numpy/numpy

Issue:
Document ndindex(shape)
This usage of `ndindex`:
```
>>> list(np.ndindex((3,2)))
[(0, 0), (0, 1), (1, 0), (1, 1), (2, 0), (2, 1)]
```
seems to work with 
```
>>> np.__version__
'1.18.4'
```
but it's not [documented](https://numpy.org/doc/stable/reference/generated/numpy.ndindex.html). Is this usage intended to be allowed? (I'd like it to be, because if `shape == 5` then `np.index(shape)` works while `np.ndindex(*shape)` does not.) If it is, could it be added to the docs?


Discussion:
We may want to make that version the preferred documented one, and just briefly mention the other option as well.  In most cases (e.g. also `arr.reshape()` where we allow both, we prefer the tuple-version in the docs).
Just to clarify this a bit - I think there are two things that make the `np.ndindex` docstring confusing:
 1. The signature of the `np.ndindex` docstring is inconsistent with the Parameters listing
 2. Additionally, the type listing in the Parameters section is incorrect: both tuples and list of ints are allowed. 
> Additionally, the type listing in the Parameters section is incorrect: both tuples and list of ints are allowed.

This has been fixed.

> The signature of the np.ndindex docstring is inconsistent with the Parameters listing

I will be raising a PR for this :)

Resolving patch:
diff --git a/numpy/lib/index_tricks.py b/numpy/lib/index_tricks.py
--- a/numpy/lib/index_tricks.py
+++ b/numpy/lib/index_tricks.py
@@ -611,7 +611,7 @@ class ndindex:
 
     Parameters
     ----------
-    `*args` : ints, or a single tuple of ints
+    shape : ints, or a single tuple of ints
         The size of each dimension of the array can be passed as 
         individual parameters or as the elements of a tuple.
 


Test patch:
Repository: numpy/numpy

Issue:
BUG: wrong or typo in signature for np.fromiter
gen = (0 for _ in range(3)
np.fromiter(iterable=gen,dtype='int') # fails
np.fromiter(iter=gen,dtype='int') # works

signature in docs and in core.multiarray declared as iterable

np.__version__
Out[8]: '1.13.3'


Discussion:

Resolving patch:
diff --git a/numpy/core/_add_newdocs.py b/numpy/core/_add_newdocs.py
--- a/numpy/core/_add_newdocs.py
+++ b/numpy/core/_add_newdocs.py
@@ -1147,13 +1147,13 @@
 
 add_newdoc('numpy.core.multiarray', 'fromiter',
     """
-    fromiter(iterable, dtype, count=-1, *, like=None)
+    fromiter(iter, dtype, count=-1, *, like=None)
 
     Create a new 1-dimensional array from an iterable object.
 
     Parameters
     ----------
-    iterable : iterable object
+    iter : iterable object
         An iterable object providing data for the array.
     dtype : data-type
         The data-type of the returned array.


Test patch:
Repository: numpy/numpy

Issue:
DOC: Update fill_diagonal docstring
The current parameter description for `fill_diagonal` states that the fill value `val` must be a scalar. However, no input-checking is done on `val` and it turns out that array-likes with the same first dimension as `a` will also work, for example::

```python
>>> a = np.zeros((4, 5))
array([[0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.]])
>>> np.fill_diagonal(a, np.arange(a.shape[0]))
>>> a
array([[0., 0., 0., 0., 0.],
       [0., 1., 0., 0., 0.],
       [0., 0., 2., 0., 0.],
       [0., 0., 0., 3., 0.]])
```

There are also already some examples in the docstring that use lists to fill the diagonal.
DOC: Update fill_diagonal docstring
The current parameter description for `fill_diagonal` states that the fill value `val` must be a scalar. However, no input-checking is done on `val` and it turns out that array-likes with the same first dimension as `a` will also work, for example::

```python
>>> a = np.zeros((4, 5))
array([[0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.],
       [0., 0., 0., 0., 0.]])
>>> np.fill_diagonal(a, np.arange(a.shape[0]))
>>> a
array([[0., 0., 0., 0., 0.],
       [0., 1., 0., 0., 0.],
       [0., 0., 2., 0., 0.],
       [0., 0., 0., 3., 0.]])
```

There are also already some examples in the docstring that use lists to fill the diagonal.


Discussion:
Hey @rossbar I'll take this one on!
Hey @rossbar I'll take this one on!

Resolving patch:
diff --git a/numpy/lib/index_tricks.py b/numpy/lib/index_tricks.py
--- a/numpy/lib/index_tricks.py
+++ b/numpy/lib/index_tricks.py
@@ -769,9 +769,11 @@ def fill_diagonal(a, val, wrap=False):
     a : array, at least 2-D.
       Array whose diagonal is to be filled, it gets modified in-place.
 
-    val : scalar
-      Value to be written on the diagonal, its type must be compatible with
-      that of the array a.
+    val : scalar or array_like
+      Value(s) to write on the diagonal. If `val` is scalar, the value is
+      written along the diagonal. If array-like, the flattened `val` is
+      written along the diagonal, repeating if necessary to fill all
+      diagonal entries.
 
     wrap : bool
       For tall matrices in NumPy version up to 1.6.2, the


Test patch: