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

Issue:
DOC: doc unclear for np.interp
https://docs.scipy.org/doc/numpy/reference/generated/numpy.interp.html

"Returns the one-dimensional piecewise linear interpolant to a function" doesn't look right - I think it should be "Returns the one-dimensional piecewise linear interpolant to a function, evaluated at x".

Also, "The x-coordinates of the interpolated values" should be "The x-coordinates of the points at which to calculate the interpolated values".


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
@@ -1181,12 +1181,12 @@ def interp(x, xp, fp, left=None, right=None, period=None):
     One-dimensional linear interpolation.
 
     Returns the one-dimensional piecewise linear interpolant to a function
-    with given values at discrete data-points.
+    with given discrete data points (`xp`, `fp`), evaluated at `x`.
 
     Parameters
     ----------
     x : array_like
-        The x-coordinates of the interpolated values.
+        The x-coordinates at which to evaluate the interpolated values.
 
     xp : 1-D sequence of floats
         The x-coordinates of the data points, must be increasing if argument


Test patch:
Repository: numpy/numpy

Issue:
Regression: np.ma.masked_values(..., shrink=True) no longer works
The [documentation for `np.ma.masked_values()`](https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.ma.masked_values.html) explains the role of the `shrink` option (which defaults to True) as follows:

> Whether to collapse a mask full of False to nomask.

In Numpy <= 1.13.3, this works correctly:

```
$ python -c 'import numpy as np; print(repr(np.ma.masked_values(np.arange(10.0), -1)))'
masked_array(data = [ 0.  1.  2.  3.  4.  5.  6.  7.  8.  9.],
             mask = False,
       fill_value = -1.0)
```

In Numpy >= 1.14.0 and on master, it is broken:

```
$ python -c 'import numpy as np; print(repr(np.ma.masked_values(np.arange(10.0), -1)))'
masked_array(data=[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0],
             mask=[False, False, False, False, False, False, False, False,
                   False, False],
       fill_value=-1.0)
```


Discussion:
@eric-wieser This looks like yours (and mine :), #10232.
This looks like a bug in `np.ma.array(..., shrink=True)` that was never previously exposed.
So, the `shrink` argument to `np.ma.array` is documented as:

> Whether to force compression of an empty mask. Default is True.

This is only used in exactly one case - when `shrink=True, keep_mask=False`, it means "don't expand `nomask` to an array of zeros"

This is super-specific, and not a reasonable interpretation of the documentation.

So I think that we can probably add back the shrinking to `masked_values`, but we should deprecate the argument to `MaskedArray.__new__`, since it's probably used only ever in error.
We need to make a decision here. Just marking for future reference.
@eric-wieser Could you make a PR with your suggestion here?

Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -2319,8 +2319,10 @@ def masked_values(x, value, rtol=1e-5, atol=1e-8, copy=True, shrink=True):
         mask = np.isclose(xnew, value, atol=atol, rtol=rtol)
     else:
         mask = umath.equal(xnew, value)
-    return masked_array(
-        xnew, mask=mask, copy=copy, fill_value=value, shrink=shrink)
+    ret = masked_array(xnew, mask=mask, copy=copy, fill_value=value)
+    if shrink:
+        ret.shrink_mask()
+    return ret
 
 
 def masked_invalid(a, copy=True):


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
@@ -4904,6 +4904,12 @@ def test_masked_values(self):
         res = np.ma.masked_values(np.inf, -np.inf)
         assert_equal(res.mask, False)
 
+        res = np.ma.masked_values([1, 2, 3, 4], 5, shrink=True)
+        assert_(res.mask is np.ma.nomask)
+
+        res = np.ma.masked_values([1, 2, 3, 4], 5, shrink=False)
+        assert_equal(res.mask, [False] * 4)
+
 
 def test_masked_array():
     a = np.ma.array([0, 1, 2, 3], mask=[0, 0, 1, 0])
Repository: numpy/numpy

Issue:
np.histogram erroneously emit warning when density=False
As seen in https://travis-ci.org/ejeschke/ginga/jobs/395720074 . The actual code in Ginga calling histogram is:
```python
# get image histogram
hist, bins = numpy.histogram(some_array, hashsize, density=False)
```
Note that `normed` was not used. However, it caused this warning in Numpy ~~dev~~ prerelease:
```python
        else:
            if normed is not None:
                # 2018-06-13, numpy 1.15.0 (this was not noisily deprecated in 1.6)
                warnings.warn(
                        "Passing normed=False is deprecated, and has no effect. "
                        "Consider passing the density argument instead.",
>                       DeprecationWarning, stacklevel=2)
E               DeprecationWarning: Passing normed=False is deprecated, and has no effect. Consider passing the density argument instead.
```

I think this is caused by #11352 . When `density=False`, it goes into the logic block that forces `normed=False`, which resulted in it going into this logic block in `np.histogram()`:
```python
else:
    if normed is not None:
        ...
```

cc @ejeschke


Discussion:
Introduced in #11323 / #11352 

Resolving patch:
diff --git a/numpy/lib/histograms.py b/numpy/lib/histograms.py
--- a/numpy/lib/histograms.py
+++ b/numpy/lib/histograms.py
@@ -782,7 +782,7 @@ def histogram(a, bins=10, range=None, normed=None, weights=None,
                     "The normed argument is ignored when density is provided. "
                     "In future passing both will result in an error.",
                     DeprecationWarning, stacklevel=2)
-        normed = False
+        normed = None
 
     if density:
         db = np.array(np.diff(bin_edges), float)


Test patch:
diff --git a/numpy/lib/tests/test_histograms.py b/numpy/lib/tests/test_histograms.py
--- a/numpy/lib/tests/test_histograms.py
+++ b/numpy/lib/tests/test_histograms.py
@@ -78,6 +78,10 @@ def test_density(self):
         assert_array_equal(a, .1)
         assert_equal(np.sum(a * np.diff(b)), 1)
 
+        # Test that passing False works too
+        a, b = histogram(v, bins, density=False)
+        assert_array_equal(a, [1, 2, 3, 4])
+
         # Variale bin widths are especially useful to deal with
         # infinities.
         v = np.arange(10)
Repository: numpy/numpy

Issue:
np.load() fails to read empty archive created by np.savez()
Try this:

    np.savez('nothing.npz') # OK
    np.load('nothing.npz') # error

Loading fails:

    OSError: Failed to interpret file 'nothing.npz' as a pickle

It should succeed (and give you an object with no arrays inside).  Likewise for `savez_compressed()` (which also currently fails).

I'm using NumPy 1.13.1.


Discussion:
Implementation of `_savez` (which both `savez` and`savez_compressed` use underneath) makes it possible to create empty archive, which `load` function cannot unpickle later:
```python
_pickle.UnpicklingError: A load persistent id instruction was encountered,
but no persistent_load function was specified.
```

Can we add `array` as a required argument to `savez` and `savez_compressed` function calls?
Because currently only filename is required:
```python
def savez(file, *args, **kwds):
    ...

def savez_compressed(file, *args, **kwds):
    ...
```

It will be also more compatible with `save` function:
```python
def save(file, arr, allow_pickle=True, fix_imports=True):
    ...
```

Resolving patch:
diff --git a/numpy/lib/npyio.py b/numpy/lib/npyio.py
--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -412,12 +412,13 @@ def load(file, mmap_mode=None, allow_pickle=True, fix_imports=True,
     try:
         # Code to distinguish from NumPy binary files and pickles.
         _ZIP_PREFIX = b'PK\x03\x04'
+        _ZIP_SUFFIX = b'PK\x05\x06' # empty zip files start with this
         N = len(format.MAGIC_PREFIX)
         magic = fid.read(N)
         # If the file size is less than N, we need to make sure not
         # to seek past the beginning of the file
         fid.seek(-min(N, len(magic)), 1)  # back-up
-        if magic.startswith(_ZIP_PREFIX):
+        if magic.startswith(_ZIP_PREFIX) or magic.startswith(_ZIP_SUFFIX):
             # zip-file (assume .npz)
             # Transfer file ownership to NpzFile
             tmp = own_fid


Test patch:
diff --git a/numpy/lib/tests/test_format.py b/numpy/lib/tests/test_format.py
--- a/numpy/lib/tests/test_format.py
+++ b/numpy/lib/tests/test_format.py
@@ -852,3 +852,10 @@ def test_large_archive():
         new_a = np.load(f)["arr"]
 
     assert_(a.shape == new_a.shape)
+
+
+def test_empty_npz():
+    # Test for gh-9989
+    fname = os.path.join(tempdir, "nothing.npz")
+    np.savez(fname)
+    np.load(fname)
Repository: numpy/numpy

Issue:
Source link in doc of `printoptions` goes to contextlib
The source link in [the documentation of the new `printoptions` context manager](https://docs.scipy.org/doc/numpy/reference/generated/numpy.printoptions.html?highlight=printoption) has the wrong link target: it goes to the invalid
```
http://github.com/anaconda3/lib/python3.6/contextlib.py#L281-L311
```
Seems like an issue with the link auto-generation machinery, maybe even with other decorated functions?


Discussion:
I think this might be a sphinx bug, assuming we're using [`sphinx.ext.linkcode`](http://www.sphinx-doc.org/en/master/usage/extensions/linkcode.html)
Nope, this is a bug in our own code - good find!

https://github.com/numpy/numpy/blob/83828f52b287fefb3d8753a21bd3441997a4d687/doc/source/conf.py#L303-L348

In particular, `inspect.getsourcefile` will not behave usefully on a contextlib contextmanager. `inspect.unwrap` should solve that problem
This relates to https://bugs.python.org/issue1764286

Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -321,6 +321,15 @@ def linkcode_resolve(domain, info):
         except Exception:
             return None
 
+    # strip decorators, which would resolve to the source of the decorator
+    # possibly an upstream bug in getsourcefile, bpo-1764286
+    try:
+        unwrap = inspect.unwrap
+    except AttributeError:
+        pass
+    else:
+        obj = unwrap(obj)
+
     try:
         fn = inspect.getsourcefile(obj)
     except Exception:


Test patch:
Repository: numpy/numpy

Issue:
numpy.polynomial.polynomial.polyfit and numpy.polyfit return coefficients in different order
### Summary

This may be a 'historical reasons' issue, but it looks like ``numpy.polynomial.polynomial.polyfit`` and ``numpy.polyfit`` return coefficients in reverse order from each other. I wonder if one of the functions should be deprecated from the public API in future, as having two functions with the same name in the same package that operate differently can lead to confusion?

### Reproducing code example:

```python
import numpy as np
from numpy.polynomial.polynomial import polyfit

x = np.linspace(0, 1, 100)
y = x ** 3

p1 = np.polyfit(x, y, 3)
p2 = polyfit(x, y, 3)

print('p1', p1)
print('p2', p2)
```

### Result

```
p1 [ 1.00000000e+00  4.64782291e-16 -7.05817953e-16 -1.47054969e-17]
p2 [-1.93895090e-16  8.46391197e-16 -7.28660556e-16  1.00000000e+00]
```

### Numpy/Python version information:

Python 3.6, Numpy 1.15.0, installed with conda.




Discussion:
It was the original intention to deprecate the old, but that did not fly due to its wide use. We should probably add a note to `polyfit` promoting the new function. BTW, `numpy.polynomial.polynomial.polyfit` is intended as a building block, users should be using `numpy.polynomial.Polynomial.fit`, i.e., the Polynomial class function.

Resolving patch:
diff --git a/numpy/lib/polynomial.py b/numpy/lib/polynomial.py
--- a/numpy/lib/polynomial.py
+++ b/numpy/lib/polynomial.py
@@ -396,7 +396,12 @@ def polyfit(x, y, deg, rcond=None, full=False, w=None, cov=False):
 
     Fit a polynomial ``p(x) = p[0] * x**deg + ... + p[deg]`` of degree `deg`
     to points `(x, y)`. Returns a vector of coefficients `p` that minimises
-    the squared error.
+    the squared error in the order `deg`, `deg-1`, ... `0`.
+
+    The `Polynomial.fit <numpy.polynomial.polynomial.Polynomial.fit>` class
+    method is recommended for new code as it is more stable numerically. See
+    the documentation for the method for more information, or the convenience
+    function `polynomial.polyfit <numpy.polynomial.polynomial.polyfit>`.
 
     Parameters
     ----------
diff --git a/numpy/polynomial/_polybase.py b/numpy/polynomial/_polybase.py
--- a/numpy/polynomial/_polybase.py
+++ b/numpy/polynomial/_polybase.py
@@ -860,7 +860,9 @@ class domain in NumPy 1.4 and ``None`` in later versions.
         -------
         new_series : series
             A series that represents the least squares fit to the data and
-            has the domain specified in the call.
+            has the domain and window specified in the call. If the
+            coefficients for the unscaled and unshifted basis polynomials are
+            of interest, do ``new_series.convert().coef``
 
         [resid, rank, sv, rcond] : list
             These values are only returned if `full` = True


Test patch:
Repository: numpy/numpy

Issue:
MAINT: Remove surviving and unused list comprehension from _polybase
Lines 320 to 325 of `numpy/polynomial/_polybase.py` contains the following code:

```
        # filter out uninteresting coefficients
        filtered_coeffs = [
            (i, c)
            for i, c in enumerate(self.coef)
            # if not (c == 0)  # handle NaN
        ]
```

A few things to note:
1) the comment no longer describes what the comprehension does
2) the conditional is commented out
3) resulting list is never used

Looks like this is just some leftover code from a prior implementation that has caused no problems, as so has been overlooked.


Discussion:

Resolving patch:
diff --git a/numpy/polynomial/_polybase.py b/numpy/polynomial/_polybase.py
--- a/numpy/polynomial/_polybase.py
+++ b/numpy/polynomial/_polybase.py
@@ -317,13 +317,6 @@ def _repr_latex_(self):
             )
             needs_parens = True
 
-        # filter out uninteresting coefficients
-        filtered_coeffs = [
-            (i, c)
-            for i, c in enumerate(self.coef)
-            # if not (c == 0)  # handle NaN
-        ]
-
         mute = r"\color{{LightGray}}{{{}}}".format
 
         parts = []


Test patch:
Repository: numpy/numpy

Issue:
MAINT: _polybase __div__ method
Line 420 - 422 of `numpy/polynomial/_polybase.py` has the following method:

```
    def __div__(self, other):
        # set to __floordiv__,  /, for now.
        return self.__floordiv__(other)
```

This  implies the original author may have intended to come back and implement some other `__div__` method here. Is there a consensus on whether we would want to do that, remove the comment, or kick the can down the road?


Discussion:
Python 2 compatibility. There is no true divide for polynomials, at least without going to infinite series, so this operator could be deprecated at some future time after Python 2 is dropped. The `//` operator was new in Python 2.2.
Thanks for the context!
> this operator could be deprecated at some future time after Python 2 is dropped

It can be removed entirely - `__div__` is never called in python 3. Feel free to create a PR that updates this comment accordingly

Resolving patch:
diff --git a/numpy/polynomial/_polybase.py b/numpy/polynomial/_polybase.py
--- a/numpy/polynomial/_polybase.py
+++ b/numpy/polynomial/_polybase.py
@@ -418,7 +418,7 @@ def __mul__(self, other):
         return self.__class__(coef, self.domain, self.window)
 
     def __div__(self, other):
-        # set to __floordiv__,  /, for now.
+        # this can be removed when python 2 support is dropped.
         return self.__floordiv__(other)
 
     def __truediv__(self, other):


Test patch:
Repository: numpy/numpy

Issue:
np.dtype('d,L') -> NameError: name 'L' is not defined
the title says it all.

additional info:
python: 2.7.9, numpy: 1.9.2, both from conda.
other combinations not using 'L' seems to work fine.



Discussion:
???What do you expect it to do?

sorry, I thought the title was clear enough.

this is what I expect
np.dtype('d,L') -> dtype([('f0', '<f8'), ('f1', '<u8')])

since
np.dtype('d,I') -> dtype([('f0', '<f8'), ('f1', '<u4')])

or am I wrong?

Just hadn't seen that construction before. Does look like a bug.

I will look through this issue.

Resolving patch:
diff --git a/numpy/core/_internal.py b/numpy/core/_internal.py
--- a/numpy/core/_internal.py
+++ b/numpy/core/_internal.py
@@ -146,7 +146,7 @@ def _reconstruct(subtype, shape, dtype):
 # format_re was originally from numarray by J. Todd Miller
 
 format_re = re.compile(br'(?P<order1>[<>|=]?)'
-                       br'(?P<repeats> *[(]?[ ,0-9L]*[)]? *)'
+                       br'(?P<repeats> *[(]?[ ,0-9]*[)]? *)'
                        br'(?P<order2>[<>|=]?)'
                        br'(?P<dtype>[A-Za-z0-9.?]*(?:\[[a-zA-Z0-9,.]+\])?)')
 sep_re = re.compile(br'\s*,\s*')


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
@@ -11,6 +11,7 @@
 from numpy.testing import (
     assert_, assert_equal, assert_array_equal, assert_raises, HAS_REFCOUNT)
 from numpy.compat import pickle
+from itertools import permutations
 
 def assert_dtype_equal(a, b):
     assert_equal(a, b)
@@ -1124,3 +1125,18 @@ def test_simple_endian_types(self):
         self.check(ctypes.c_uint16.__ctype_be__, np.dtype('>u2'))
         self.check(ctypes.c_uint8.__ctype_le__, np.dtype('u1'))
         self.check(ctypes.c_uint8.__ctype_be__, np.dtype('u1'))
+
+    all_types = set(np.typecodes['All'])
+    all_pairs = permutations(all_types, 2)
+
+    @pytest.mark.parametrize("pair", all_pairs)
+    def test_pairs(self, pair):
+        """
+        Check that np.dtype('x,y') matches [np.dtype('x'), np.dtype('y')]
+        Example: np.dtype('d,I') -> dtype([('f0', '<f8'), ('f1', '<u4')])
+        """
+        # gh-5645: check that np.dtype('i,L') can be used
+        pair_type = np.dtype('{},{}'.format(*pair))
+        expected = np.dtype([('f0', pair[0]), ('f1', pair[1])])
+        assert_equal(pair_type, expected)
+
Repository: numpy/numpy

Issue:
Regression: np.ma.masked_values(..., shrink=True) no longer works
The [documentation for `np.ma.masked_values()`](https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.ma.masked_values.html) explains the role of the `shrink` option (which defaults to True) as follows:

> Whether to collapse a mask full of False to nomask.

In Numpy <= 1.13.3, this works correctly:

```
$ python -c 'import numpy as np; print(repr(np.ma.masked_values(np.arange(10.0), -1)))'
masked_array(data = [ 0.  1.  2.  3.  4.  5.  6.  7.  8.  9.],
             mask = False,
       fill_value = -1.0)
```

In Numpy >= 1.14.0 and on master, it is broken:

```
$ python -c 'import numpy as np; print(repr(np.ma.masked_values(np.arange(10.0), -1)))'
masked_array(data=[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0],
             mask=[False, False, False, False, False, False, False, False,
                   False, False],
       fill_value=-1.0)
```


Discussion:
@eric-wieser This looks like yours (and mine :), #10232.
This looks like a bug in `np.ma.array(..., shrink=True)` that was never previously exposed.
So, the `shrink` argument to `np.ma.array` is documented as:

> Whether to force compression of an empty mask. Default is True.

This is only used in exactly one case - when `shrink=True, keep_mask=False`, it means "don't expand `nomask` to an array of zeros"

This is super-specific, and not a reasonable interpretation of the documentation.

So I think that we can probably add back the shrinking to `masked_values`, but we should deprecate the argument to `MaskedArray.__new__`, since it's probably used only ever in error.
We need to make a decision here. Just marking for future reference.
@eric-wieser Could you make a PR with your suggestion here?

Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -2320,8 +2320,10 @@ def masked_values(x, value, rtol=1e-5, atol=1e-8, copy=True, shrink=True):
         mask = np.isclose(xnew, value, atol=atol, rtol=rtol)
     else:
         mask = umath.equal(xnew, value)
-    return masked_array(
-        xnew, mask=mask, copy=copy, fill_value=value, shrink=shrink)
+    ret = masked_array(xnew, mask=mask, copy=copy, fill_value=value)
+    if shrink:
+        ret.shrink_mask()
+    return ret
 
 
 def masked_invalid(a, copy=True):


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
@@ -4996,6 +4996,12 @@ def test_masked_values(self):
         res = np.ma.masked_values(np.inf, -np.inf)
         assert_equal(res.mask, False)
 
+        res = np.ma.masked_values([1, 2, 3, 4], 5, shrink=True)
+        assert_(res.mask is np.ma.nomask)
+
+        res = np.ma.masked_values([1, 2, 3, 4], 5, shrink=False)
+        assert_equal(res.mask, [False] * 4)
+
 
 def test_masked_array():
     a = np.ma.array([0, 1, 2, 3], mask=[0, 0, 1, 0])
Repository: numpy/numpy

Issue:
MAINT: Add a RuntimeError to prove _typestr` is unused
Follow up will be to remove the preceding lines of code, once CI proves this is never hit on any platform.

This dates way back to 668950285c407593a368336ff2e737c5da84af7d, so probably has just been made redundant by one of the ~10 other loops in this file that try to assign names to types.



Discussion:

Resolving patch:
diff --git a/numpy/core/numerictypes.py b/numpy/core/numerictypes.py
--- a/numpy/core/numerictypes.py
+++ b/numpy/core/numerictypes.py
@@ -762,19 +762,6 @@ def sctype2char(sctype):
 for key in _sctype2char_dict.keys():
     cast[key] = lambda x, k=key: array(x, copy=False).astype(k)
 
-# Create the typestring lookup dictionary
-_typestr = _typedict()
-for key in _sctype2char_dict.keys():
-    if issubclass(key, allTypes['flexible']):
-        _typestr[key] = _sctype2char_dict[key]
-    else:
-        _typestr[key] = empty((1,), key).dtype.str[1:]
-
-# Make sure all typestrings are in sctypeDict
-for key, val in _typestr.items():
-    if val not in sctypeDict:
-        sctypeDict[val] = key
-
 # Add additional strings to the sctypeDict
 
 if sys.version_info[0] >= 3:
diff --git a/numpy/ma/mrecords.py b/numpy/ma/mrecords.py
--- a/numpy/ma/mrecords.py
+++ b/numpy/ma/mrecords.py
@@ -29,7 +29,6 @@
         )
 
 _byteorderconv = np.core.records._byteorderconv
-_typestr = ntypes._typestr
 
 import numpy.ma as ma
 from numpy.ma import (
@@ -48,24 +47,6 @@
 reserved_fields = ['_data', '_mask', '_fieldmask', 'dtype']
 
 
-def _getformats(data):
-    """
-    Returns the formats of arrays in arraylist as a comma-separated string.
-
-    """
-    if hasattr(data, 'dtype'):
-        return ",".join([desc[1] for desc in data.dtype.descr])
-
-    formats = ''
-    for obj in data:
-        obj = np.asarray(obj)
-        formats += _typestr[obj.dtype.type]
-        if issubclass(obj.dtype.type, ntypes.flexible):
-            formats += repr(obj.itemsize)
-        formats += ','
-    return formats[:-1]
-
-
 def _checknames(descr, names=None):
     """
     Checks that field names ``descr`` are not reserved keywords.


Test patch: