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

Issue:
fixed asscalar error on floats
fixed error encountered on passing floats to asscalar().

done at HackIllinois 2018


Discussion:
This fixes #4701, I think
Duplicates #10256, #5126

Resolving patch:
diff --git a/numpy/lib/type_check.py b/numpy/lib/type_check.py
--- a/numpy/lib/type_check.py
+++ b/numpy/lib/type_check.py
@@ -2,6 +2,7 @@
 
 """
 from __future__ import division, absolute_import, print_function
+import warnings
 
 __all__ = ['iscomplexobj', 'isrealobj', 'imag', 'iscomplex',
            'isreal', 'nan_to_num', 'real', 'real_if_close',
@@ -469,6 +470,10 @@ def asscalar(a):
     """
     Convert an array of size 1 to its scalar equivalent.
 
+    .. deprecated:: 1.16
+
+        Deprecated, use `numpy.ndarray.item()` instead.
+
     Parameters
     ----------
     a : ndarray
@@ -486,6 +491,10 @@ def asscalar(a):
     24
 
     """
+
+    # 2018-10-10, 1.16
+    warnings.warn('np.asscalar(a) is deprecated since NumPy v1.16, use '
+                  'a.item() instead', DeprecationWarning, stacklevel=1)
     return a.item()
 
 #-----------------------------------------------------------------------------


Test patch:
Repository: numpy/numpy

Issue:
polyval turns masked array into array (Trac #1884)
_Original ticket http://projects.scipy.org/numpy/ticket/1884 on 2011-06-28 by trac user mauro, assigned to @pierregm._

When using a masked array as input for polyval, then the return is an array.  I think it should be a masked array again (or at least document it that it is not).

The fix seems easy, remove the line 
x = NX.asarray(x)
from np.lib.polyval.  But presumably that line is there for a reason...



Discussion:
Attachment added by trac user mauro on 2011-06-28: [masked_and_polyfit.py](http://projects.scipy.org/numpy/attachment/ticket/1884/masked_and_polyfit.py)

Using `x = NX.asanyarray(x)` fixes this. The rest of the functions also need checking to see if there are other places where that is appropriate.


Resolving patch:
diff --git a/numpy/lib/polynomial.py b/numpy/lib/polynomial.py
--- a/numpy/lib/polynomial.py
+++ b/numpy/lib/polynomial.py
@@ -651,6 +651,8 @@ def polyval(p, x):
     for polynomials of high degree the values may be inaccurate due to
     rounding errors. Use carefully.
 
+    If `x` is a subtype of `ndarray` the return value will be of the same type.
+
     References
     ----------
     .. [1] I. N. Bronshtein, K. A. Semendyayev, and K. A. Hirsch (Eng.
@@ -673,7 +675,7 @@ def polyval(p, x):
     if isinstance(x, poly1d):
         y = 0
     else:
-        x = NX.asarray(x)
+        x = NX.asanyarray(x)
         y = NX.zeros_like(x)
     for i in range(len(p)):
         y = y * x + p[i]


Test patch:
diff --git a/numpy/polynomial/tests/test_polynomial.py b/numpy/polynomial/tests/test_polynomial.py
--- a/numpy/polynomial/tests/test_polynomial.py
+++ b/numpy/polynomial/tests/test_polynomial.py
@@ -9,7 +9,7 @@
 import numpy.polynomial.polynomial as poly
 from numpy.testing import (
     assert_almost_equal, assert_raises, assert_equal, assert_,
-    )
+    assert_array_equal)
 
 
 def trim(x):
@@ -147,6 +147,19 @@ def test_polyval(self):
             assert_equal(poly.polyval(x, [1, 0]).shape, dims)
             assert_equal(poly.polyval(x, [1, 0, 0]).shape, dims)
 
+        #check masked arrays are processed correctly
+        mask = [False, True, False]
+        mx = np.ma.array([1, 2, 3], mask=mask)
+        res = np.polyval([7, 5, 3], mx)
+        assert_array_equal(res.mask, mask)
+
+        #check subtypes of ndarray are preserved
+        class C(np.ndarray):
+            pass
+
+        cx = np.array([1, 2, 3]).view(C)
+        assert_equal(type(np.polyval([2, 3, 4], cx)), C)
+
     def test_polyvalfromroots(self):
         # check exception for broadcasting x values over root array with
         # too few dimensions
Repository: numpy/numpy

Issue:
BUG: dtype repr of subclasses of np.void throw an exception
This one is on me, I think, in #10602. I wasn't aware this was legal:

```python
>>> np.__version__
'1.13.3'
>>> class Custom(np.void): pass
>>> np.dtype(Custom)
dtype('V')
```

```python
>>> np.__version__
'1.16.0.dev0+7af8e10'
>>> class Custom(np.void): pass
>>> np.dtype(Custom)
RuntimeError: Internal error: NumPy dtype unrecognized type number
```

Not sure if this affects 1.15.0



Discussion:

Resolving patch:
diff --git a/numpy/core/_dtype.py b/numpy/core/_dtype.py
--- a/numpy/core/_dtype.py
+++ b/numpy/core/_dtype.py
@@ -138,7 +138,9 @@ def _scalar_str(dtype, short):
         else:
             return "'%sU%d'" % (byteorder, dtype.itemsize / 4)
 
-    elif dtype.type == np.void:
+    # unlike the other types, subclasses of void are preserved - but
+    # historically the repr does not actually reveal the subclass
+    elif issubclass(dtype.type, np.void):
         if _isunsized(dtype):
             return "'V'"
         else:


Test patch:
diff --git a/numpy/core/tests/test_dtype.py b/numpy/core/tests/test_dtype.py
--- a/numpy/core/tests/test_dtype.py
+++ b/numpy/core/tests/test_dtype.py
@@ -620,6 +620,25 @@ def test_empty_string_to_object(self):
         # Pull request #4722
         np.array(["", ""]).astype(object)
 
+    def test_void_subclass_unsized(self):
+        dt = np.dtype(np.record)
+        assert_equal(repr(dt), "dtype('V')")
+        assert_equal(str(dt), '|V0')
+        assert_equal(dt.name, 'record')
+
+    def test_void_subclass_sized(self):
+        dt = np.dtype((np.record, 2))
+        assert_equal(repr(dt), "dtype('V2')")
+        assert_equal(str(dt), '|V2')
+        assert_equal(dt.name, 'record16')
+
+    def test_void_subclass_fields(self):
+        dt = np.dtype((np.record, [('a', '<u2')]))
+        assert_equal(repr(dt), "dtype((numpy.record, [('a', '<u2')]))")
+        assert_equal(str(dt), "(numpy.record, [('a', '<u2')])")
+        assert_equal(dt.name, 'record16')
+
+
 class TestDtypeAttributeDeletion(object):
 
     def test_dtype_non_writable_attributes_deletion(self):
Repository: numpy/numpy

Issue:
integrate content/images on broadcasting in docs
https://scipy.github.io/old-wiki/pages/EricsBroadcastingDoc explains broadcasting well (including useful diagrams) and is linked to from https://docs.scipy.org/doc/numpy/user/basics.broadcasting.html. It is the only link to https://scipy.github.io/old-wiki left.

This content should be integrated in the user guide. There's also useful code to draw such diagrams at https://jakevdp.github.io/PythonDataScienceHandbook/02.05-computation-on-arrays-broadcasting.html


Discussion:
A different issue, but ...

The actual broadcasting doc lives in `numpy/doc/broadcasting.py`. Why is some of the documentation in `numpy/doc` and some in `doc/source/user`? Should we remove `numpy/doc` or do new users browse using our `help(numpy.doc)` system?

Resolving patch:
diff --git a/numpy/doc/broadcasting.py b/numpy/doc/broadcasting.py
--- a/numpy/doc/broadcasting.py
+++ b/numpy/doc/broadcasting.py
@@ -3,6 +3,12 @@
 Broadcasting over arrays
 ========================
 
+.. note::
+    See `this article
+    <https://numpy.org/devdocs/user/theory.broadcasting.html>`_
+    for illustrations of broadcasting concepts.
+
+
 The term broadcasting describes how numpy treats arrays with different
 shapes during arithmetic operations. Subject to certain constraints,
 the smaller array is "broadcast" across the larger array so that they
@@ -172,8 +178,5 @@
 making it a two-dimensional ``4x1`` array.  Combining the ``4x1`` array
 with ``b``, which has shape ``(3,)``, yields a ``4x3`` array.
 
-See `this article <https://scipy.github.io/old-wiki/pages/EricsBroadcastingDoc>`_
-for illustrations of broadcasting concepts.
-
 """
 from __future__ import division, absolute_import, print_function


Test patch:
Repository: numpy/numpy

Issue:
DOC: polyint typo
<!-- Please describe the issue in detail here, and fill in the fields below -->

Shouldn't the description of the parameter ```p``` in numpy.polyint be `Polynomial to integrate` instead of `Polynomial to differentiate`?



Discussion:
Yes. PR welcome.

Resolving patch:
diff --git a/numpy/lib/polynomial.py b/numpy/lib/polynomial.py
--- a/numpy/lib/polynomial.py
+++ b/numpy/lib/polynomial.py
@@ -272,7 +272,7 @@ def polyint(p, m=1, k=None):
     Parameters
     ----------
     p : array_like or poly1d
-        Polynomial to differentiate.
+        Polynomial to integrate.
         A sequence is interpreted as polynomial coefficients, see `poly1d`.
     m : int, optional
         Order of the antiderivative. (Default: 1)


Test patch:
Repository: numpy/numpy

Issue:
MismatchCAPIWarning during build
Something we might want to deal with before 1.16:

> numpy\core\setup.py:400: MismatchCAPIWarning: API mismatch detected, the C API version numbers have to be updated. Current C api version is 13, with checksum 5b0e8bbded00b166125974fc71e80a33, but recorded checksum for C API version 13 in codegen_dir/cversions.txt is a1bc756c5782853ec2e3616cf66869d8. If functions were added in the C API, you have to update C_API_VERSION  in numpy\core\setup_common.py.

The build continues despite this warning, so it's possible we just didn't notice it. This is likely my fault as part of #8955


Discussion:

Resolving patch:
diff --git a/numpy/core/code_generators/numpy_api.py b/numpy/core/code_generators/numpy_api.py
--- a/numpy/core/code_generators/numpy_api.py
+++ b/numpy/core/code_generators/numpy_api.py
@@ -402,8 +402,7 @@
     # End 1.7 API
     'PyUFunc_RegisterLoopForDescr':             (41,),
     # End 1.8 API
-    'PyUFunc_FromFuncAndDataAndSignatureAndIdentity':
-                                                (42,),
+    'PyUFunc_FromFuncAndDataAndSignatureAndIdentity': (42,),
     # End 1.16 API
 }
 


Test patch:
Repository: numpy/numpy

Issue:
BUG: functions marked with NPY_NO_EXPORT still are exported
Steps to reproduce (on linux):
- git checkout
- `python setup.py build_ext`
- choose a random function marked with the `NPY_NO_EXPORT` macro, for instance [`datetime_metadata_divides`](https://github.com/numpy/numpy/blob/v1.15.4/numpy/core/src/multiarray/_datetime.h#L108) and ~call 
 `nm build/lib*/numpy/core/_multiarray_umath*.so |grep datetime_metadata_divides`~ check that the function is not exported:
  ```
  import ctypes, numpy as np
  dll = ctypes.CDLL(np.core._multiarray_umath.__file__)
  print(getattr(dll, `datetime_metadata_divides`, None)
  ```
Note that the function appears in the result. It should not. I think the problem is in the `visibility_define` [function](https://github.com/numpy/numpy/blob/v1.15.4/numpy/core/setup.py#L379) which only hides the functions for gcc 4.

Edit: use ctypes to check for export


Discussion:

Resolving patch:
diff --git a/numpy/core/setup.py b/numpy/core/setup.py
--- a/numpy/core/setup.py
+++ b/numpy/core/setup.py
@@ -379,8 +379,9 @@ def check_mathlib(config_cmd):
 def visibility_define(config):
     """Return the define value to use for NPY_VISIBILITY_HIDDEN (may be empty
     string)."""
-    if config.check_compiler_gcc4():
-        return '__attribute__((visibility("hidden")))'
+    hide = '__attribute__((visibility("hidden")))'
+    if config.check_gcc_function_attribute(hide, 'hideme'):
+        return hide
     else:
         return ''
 


Test patch:
diff --git a/numpy/core/src/multiarray/_multiarray_tests.c.src b/numpy/core/src/multiarray/_multiarray_tests.c.src
--- a/numpy/core/src/multiarray/_multiarray_tests.c.src
+++ b/numpy/core/src/multiarray/_multiarray_tests.c.src
@@ -2066,3 +2066,9 @@ init_multiarray_tests(void)
     }
     return RETVAL;
 }
+
+NPY_NO_EXPORT int
+test_not_exported(void)
+{
+    return 1;
+}
diff --git a/numpy/tests/test_public_api.py b/numpy/tests/test_public_api.py
--- a/numpy/tests/test_public_api.py
+++ b/numpy/tests/test_public_api.py
@@ -4,7 +4,10 @@
 
 import numpy as np
 import pytest
-
+try:
+    import ctypes
+except ImportError:
+    ctypes = None
 
 def check_dir(module, module_name=None):
     """Returns a mapping of all objects with the wrong __module__ attribute."""
@@ -75,3 +78,12 @@ def test_numpy_linalg():
 def test_numpy_fft():
     bad_results = check_dir(np.fft)
     assert bad_results == {}
+
+@pytest.mark.skipif(ctypes is None,
+                    reason="ctypes not available in this python")
+def test_NPY_NO_EXPORT():
+    cdll = ctypes.CDLL(np.core._multiarray_tests.__file__)
+    # Make sure an arbitrary NPY_NO_EXPORT function is actually hidden
+    f = getattr(cdll, 'test_not_exported', None)
+    assert f is None, ("'test_not_exported' is mistakenly exported, "
+                      "NPY_NO_EXPORT does not work")
Repository: numpy/numpy

Issue:
Update NDArrayOperatorsMixin to implement __matmul__ using np.matmul
`np.matmul` is now a ufunc (thanks to #12219), so we can support it with NDArrayOperatorsMixin now -- these lines in the docstring are now out of date!
https://github.com/numpy/numpy/blob/82428bb72589c6fd781689feb1f501a6a29c6fdc/numpy/lib/mixins.py#L72-L73

This isn't a strict blocker for 1.16 but it would be good to get it in if possible.


Discussion:

Resolving patch:
diff --git a/numpy/lib/mixins.py b/numpy/lib/mixins.py
--- a/numpy/lib/mixins.py
+++ b/numpy/lib/mixins.py
@@ -69,9 +69,6 @@ class NDArrayOperatorsMixin(object):
     deferring to the ``__array_ufunc__`` method, which subclasses must
     implement.
 
-    This class does not yet implement the special operators corresponding
-    to ``matmul`` (``@``), because ``np.matmul`` is not yet a NumPy ufunc.
-
     It is useful for writing classes that do not inherit from `numpy.ndarray`,
     but that should support arithmetic and numpy universal functions like
     arrays as described in `A Mechanism for Overriding Ufuncs
@@ -155,6 +152,8 @@ def __repr__(self):
     __add__, __radd__, __iadd__ = _numeric_methods(um.add, 'add')
     __sub__, __rsub__, __isub__ = _numeric_methods(um.subtract, 'sub')
     __mul__, __rmul__, __imul__ = _numeric_methods(um.multiply, 'mul')
+    __matmul__, __rmatmul__, __imatmul__ = _numeric_methods(
+        um.matmul, 'matmul')
     if sys.version_info.major < 3:
         # Python 3 uses only __truediv__ and __floordiv__
         __div__, __rdiv__, __idiv__ = _numeric_methods(um.divide, 'div')


Test patch:
diff --git a/numpy/lib/tests/test_mixins.py b/numpy/lib/tests/test_mixins.py
--- a/numpy/lib/tests/test_mixins.py
+++ b/numpy/lib/tests/test_mixins.py
@@ -199,6 +199,17 @@ def test_reflected_binary_methods(self):
             err_msg = 'failed for operator {}'.format(op)
             _assert_equal_type_and_value(expected, actual, err_msg=err_msg)
 
+    def test_matmul(self):
+        array = np.array([1, 2], dtype=np.float64)
+        array_like = ArrayLike(array)
+        expected = ArrayLike(np.float64(5))
+        _assert_equal_type_and_value(expected, np.matmul(array_like, array))
+        if not PY2:
+            _assert_equal_type_and_value(
+                expected, operator.matmul(array_like, array))
+            _assert_equal_type_and_value(
+                expected, operator.matmul(array, array_like))
+
     def test_ufunc_at(self):
         array = ArrayLike(np.array([1, 2, 3, 4]))
         assert_(np.negative.at(array, np.array([0, 1])) is None)
Repository: numpy/numpy

Issue:
records.fromfile - 64 bit incompatibility 
Hello,

https://github.com/numpy/numpy/blob/983bbb5ed2495e034b437a0b58a69371d4dfed74/numpy/core/records.py#L796

Seems like unfortunately numpy.core.records.fromfile method uses 32 bit integers. Makes it impossible to read data larger than 4GB.

Python 3.7.1 64 bit
numpy 1.15.4 (numpy-1.15.4-cp37-none-win_amd64.whl)

call:

`raw_data = numpy.core.records.fromfile(io_input,
                                           shape=420453029, offset=0,
                                           formats='i4,u4,i4',
                                           names='t,k,n',
                                           byteorder='<')`


Discussion:

Resolving patch:
diff --git a/numpy/core/records.py b/numpy/core/records.py
--- a/numpy/core/records.py
+++ b/numpy/core/records.py
@@ -783,13 +783,13 @@ def fromfile(fd, dtype=None, shape=None, offset=0, formats=None,
 
     itemsize = descr.itemsize
 
-    shapeprod = sb.array(shape).prod()
+    shapeprod = sb.array(shape).prod(dtype=nt.intp)
     shapesize = shapeprod * itemsize
     if shapesize < 0:
         shape = list(shape)
-        shape[shape.index(-1)] = size / -shapesize
+        shape[shape.index(-1)] = size // -shapesize
         shape = tuple(shape)
-        shapeprod = sb.array(shape).prod()
+        shapeprod = sb.array(shape).prod(dtype=nt.intp)
 
     nbytes = shapeprod * itemsize
 


Test patch:
Repository: numpy/numpy

Issue:
UFunc benchmarks complaining lack of coverage of matmul and _arg
When running benchmarks, a warning appears (see https://github.com/numpy/numpy/pull/12666#issuecomment-451790069) that
```
[  0.00%] ···· Missing ufunc '_arg'                                                                                                                                                                                                                  
               Missing ufunc 'matmul'      
```
This originates on
https://github.com/numpy/numpy/blob/master/benchmarks/benchmarks/bench_ufunc.py#L25

I think `matmul` may well be tested elsewhere, so can be excluded here. `np.core.umath_arg.__doc__` suggests `_arg` is for testing purposes only; am not sure why it is exported.


Discussion:

Resolving patch:
diff --git a/benchmarks/benchmarks/bench_ufunc.py b/benchmarks/benchmarks/bench_ufunc.py
--- a/benchmarks/benchmarks/bench_ufunc.py
+++ b/benchmarks/benchmarks/bench_ufunc.py
@@ -15,7 +15,7 @@
           'isinf', 'isnan', 'isnat', 'lcm', 'ldexp', 'left_shift', 'less',
           'less_equal', 'log', 'log10', 'log1p', 'log2', 'logaddexp',
           'logaddexp2', 'logical_and', 'logical_not', 'logical_or',
-          'logical_xor', 'maximum', 'minimum', 'mod', 'modf', 'multiply',
+          'logical_xor', 'matmul', 'maximum', 'minimum', 'mod', 'modf', 'multiply',
           'negative', 'nextafter', 'not_equal', 'positive', 'power',
           'rad2deg', 'radians', 'reciprocal', 'remainder', 'right_shift',
           'rint', 'sign', 'signbit', 'sin', 'sinh', 'spacing', 'sqrt',
diff --git a/numpy/core/umath.py b/numpy/core/umath.py
--- a/numpy/core/umath.py
+++ b/numpy/core/umath.py
@@ -9,7 +9,7 @@
 from . import _multiarray_umath
 from numpy.core._multiarray_umath import *
 from numpy.core._multiarray_umath import (
-    _UFUNC_API, _add_newdoc_ufunc, _arg, _ones_like
+    _UFUNC_API, _add_newdoc_ufunc, _ones_like
     )
 
 __all__ = [
@@ -18,7 +18,7 @@
     'FPE_DIVIDEBYZERO', 'FPE_INVALID', 'FPE_OVERFLOW', 'FPE_UNDERFLOW', 'NAN',
     'NINF', 'NZERO', 'PINF', 'PZERO', 'SHIFT_DIVIDEBYZERO', 'SHIFT_INVALID',
     'SHIFT_OVERFLOW', 'SHIFT_UNDERFLOW', 'UFUNC_BUFSIZE_DEFAULT',
-    'UFUNC_PYVALS_NAME', '_add_newdoc_ufunc', '_arg', 'absolute', 'add',
+    'UFUNC_PYVALS_NAME', '_add_newdoc_ufunc', 'absolute', 'add',
     'arccos', 'arccosh', 'arcsin', 'arcsinh', 'arctan', 'arctan2', 'arctanh',
     'bitwise_and', 'bitwise_or', 'bitwise_xor', 'cbrt', 'ceil', 'conj',
     'conjugate', 'copysign', 'cos', 'cosh', 'deg2rad', 'degrees', 'divide',


Test patch:
diff --git a/numpy/core/tests/test_umath_complex.py b/numpy/core/tests/test_umath_complex.py
--- a/numpy/core/tests/test_umath_complex.py
+++ b/numpy/core/tests/test_umath_complex.py
@@ -5,7 +5,8 @@
 import pytest
 
 import numpy as np
-import numpy.core.umath as ncu
+# import the c-extension module directly since _arg is not exported via umath
+import numpy.core._multiarray_umath as ncu
 from numpy.testing import (
     assert_raises, assert_equal, assert_array_equal, assert_almost_equal
     )
Repository: numpy/numpy

Issue:
Updates to `nditer` docs?
I was looking through the instructions on how to use `flags=['multi_index']` at https://docs.scipy.org/doc/numpy/reference/arrays.nditer.html#tracking-an-index-or-multi-index. The recommended way of doing

```
it = np.nditer(a, flags=['multi_index'], op_flags=['writeonly'])
with it:
    while not it.finished:
        it[0] = it.multi_index[1] - it.multi_index[0]
        it.iternext()
```

seems a bit stilted and unpythonic, given that you can avoid iterating manually at all:

```
it = np.nditer(a, flags=['multi_index'], op_flags=['writeonly'])
with it:
    for x in it:
        x[...] = it.multi_index[1] - it.multi_index[0]
```

This description appears for all versions at least up to 1.16.0.

I agree that the alternative looping notation should be mentioned, perhaps in a section on "Fine Grained Loop Control" or "Alternative Iteration Method" or something similar, but it's not necessary to show the feature as the only way of iterating with an index.

If my suggestion meets with a favorable response, I'd be happy to submit a patch. Or I can do that if you just want to see whatI had in mind.

This issue is based on my answer to https://stackoverflow.com/q/54220875/2988730

Another item that came up in the same answer is that at least in version 1.12.0, `nditer` was not a context manager and did not have a close method. I propose adding some `since 1.1....` tags in a few places to document this explicitly.


Discussion:
I think your version of the example is indeed clearer.

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
@@ -386,12 +386,12 @@
     >>> luf(lambda i,j:i*i + j/2, a, b)
     array([  0.5,   1.5,   4.5,   9.5,  16.5])
 
-    If operand flags `"writeonly"` or `"readwrite"` are used the operands may
-    be views into the original data with the `WRITEBACKIFCOPY` flag. In this case
-    nditer must be used as a context manager or the nditer.close
-    method must be called before using the result. The temporary
-    data will be written back to the original data when the `__exit__`
-    function is called but not before:
+    If operand flags `"writeonly"` or `"readwrite"` are used the
+    operands may be views into the original data with the
+    `WRITEBACKIFCOPY` flag. In this case `nditer` must be used as a
+    context manager or the `nditer.close` method must be called before
+    using the result. The temporary data will be written back to the
+    original data when the `__exit__` function is called but not before:
 
     >>> a = np.arange(6, dtype='i4')[::-2]
     >>> with np.nditer(a, [],
@@ -413,6 +413,8 @@
     `x.data` will still point at some part of `a.data`, and writing to
     one will affect the other.
 
+    Context management and the `close` method appeared in version 1.15.0.
+
     """)
 
 # nditer methods
@@ -568,6 +570,8 @@
 
     Resolve all writeback semantics in writeable operands.
 
+    .. versionadded:: 1.15.0
+
     See Also
     --------
 


Test patch: