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

Issue:
Doc improvement suggestions: list () and tolist () are very different.
numpy 1.15.4
python 3.7.1

I refer to this doc but I spent a lot of time discovering the following.

https://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.tolist.html?highlight=tolist#numpy.ndarray.tolist

```python
import numpy as np

npA=np.uint32([1,2,3])

listA=list(npA)
print(type(listA)) # <class 'list'>
print(type(listA[0])) # <class 'numpy.uint32'>

listA2 = npA.tolist()
print(type(listA2)) # <class 'list'>
print(type(listA2[0])) # <class 'int'>
```

I wanted to calculate numbers greater than 32bit integers, but I should have used tolist() only.


Discussion:
What would you suggest to make `tolist` more discoverable?
I hope that there is a mutual link between "https://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.tolist.html?highlight=tolist#numpy.ndarray.tolist" and "https://docs.python.org/3/library/stdtypes.html#list".
Updating these docs would probably do the trick:

> For a 1D array, `a.tolist()` is almost the same as `list(a)`:
> ```
> >>> a = np.array([1, 2])
> >>> list(a)
> [1, 2]
> >>> a.tolist()
> [1, 2]
> ```

We should draw attention to the fact that one list contains numpy scalars, while the other contains python scalars

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
@@ -3953,15 +3953,22 @@
 
     Examples
     --------
-    For a 1D array, ``a.tolist()`` is almost the same as ``list(a)``:
+    For a 1D array, ``a.tolist()`` is almost the same as ``list(a)``, 
+    except that ``tolist`` changes numpy scalars to Python scalars:
 
-    >>> a = np.array([1, 2])
-    >>> list(a)
+    >>> a = np.uint32([1, 2])
+    >>> a_list = list(a)
+    >>> a_list
     [1, 2]
-    >>> a.tolist()
+    >>> type(a_list[0])
+    <class 'numpy.uint32'>
+    >>> a_tolist = a.tolist()
+    >>> a_tolist
     [1, 2]
+    >>> type(a_tolist[0])
+    <class 'int'>
 
-    However, for a 2D array, ``tolist`` applies recursively:
+    Additionally, for a 2D array, ``tolist`` applies recursively:
 
     >>> a = np.array([[1, 2], [3, 4]])
     >>> list(a)
@@ -4246,7 +4253,7 @@
 
     See Also
     --------
-    vectorize : evaluates pyfunc over input arrays using broadcasting rules of numpy
+    vectorize : Evaluates pyfunc over input arrays using broadcasting rules of numpy.
 
     Notes
     -----


Test patch:
Repository: numpy/numpy

Issue:
distutils/misc_util.py Configuration settings lead to ImportError DLL load failed
When building NumPy from the source on Windows 10, the resulting `.libs` folder is not added to the path.

### Reproducing code example:
The regular 

```bash
python setup.py build
python setup.py install
```
machinery succeeds however afterwards numpy import fails with the recently reported `ImportError`s elsewhere, say, #14896 and others.

This happens also on SciPy builds which were successfully working until I switched to Python 3.8. This is also reported on SciPy https://github.com/scipy/scipy/issues/11062

It seems like the generated `__config__.py` has the lines

https://github.com/numpy/numpy/blob/6e75b9ab7888e2d807893a8237811f97f605547e/numpy/distutils/misc_util.py#L2324-L2335

Somehow, .libs folder is not present on the `src.win-amd64-3.8` but it is created in `lib.win-amd64-3.8` and for reasons I have not yet understood, this if branch is not entered. On the linked SciPy issue, the file is modified manually to add the libs to the path.

Hence I am under the impression that it is not necessarily an Anaconda issue but something has changed along the way, that is maybe, Python3.8 related.


Discussion:
Python 3.8 on windows no longer searches `os.environ['PATH']` for DLLs, you must use the new [os.add_dll_directory](https://docs.python.org/3/library/os.html#os.add_dll_directory) function instead. 

The code in numpy (and very recently in scipy) works around this by [generating a `_distributor_init.py`](https://github.com/numpy/numpy/blob/v1.17.4/tools/openblas_support.py#L140) file that preloads dependent DLLs by name. We chose this solution since we needed to release a fix while CPython worked out the `os.add_dll_directory` interface. Now that version 3.8 is released, perhaps we should revisit the code you pointed to, and add a path for 3.8+ behaviour. 
Indeed changing to `os.add_dll_directory()` makes the SciPy import error vanish. Though I can't explain why Python 3.7 also fails in the linked issue. 

I'll propose that fix on the SciPy side. NumPy side seems a bit more involved.

Resolving patch:
diff --git a/numpy/distutils/misc_util.py b/numpy/distutils/misc_util.py
--- a/numpy/distutils/misc_util.py
+++ b/numpy/distutils/misc_util.py
@@ -2329,8 +2329,11 @@ def generate_config_py(target):
             extra_dll_dir = os.path.join(os.path.dirname(__file__), '.libs')
 
             if sys.platform == 'win32' and os.path.isdir(extra_dll_dir):
-                os.environ.setdefault('PATH', '')
-                os.environ['PATH'] += os.pathsep + extra_dll_dir
+                if sys.version_info >= (3, 8):
+                    os.add_dll_directory(extra_dll_dir)
+                else:
+                    os.environ.setdefault('PATH', '')
+                    os.environ['PATH'] += os.pathsep + extra_dll_dir
 
             """))
 


Test patch:
Repository: numpy/numpy

Issue:
distutils/misc_util.py Configuration settings lead to ImportError DLL load failed
When building NumPy from the source on Windows 10, the resulting `.libs` folder is not added to the path.

### Reproducing code example:
The regular 

```bash
python setup.py build
python setup.py install
```
machinery succeeds however afterwards numpy import fails with the recently reported `ImportError`s elsewhere, say, #14896 and others.

This happens also on SciPy builds which were successfully working until I switched to Python 3.8. This is also reported on SciPy https://github.com/scipy/scipy/issues/11062

It seems like the generated `__config__.py` has the lines

https://github.com/numpy/numpy/blob/6e75b9ab7888e2d807893a8237811f97f605547e/numpy/distutils/misc_util.py#L2324-L2335

Somehow, .libs folder is not present on the `src.win-amd64-3.8` but it is created in `lib.win-amd64-3.8` and for reasons I have not yet understood, this if branch is not entered. On the linked SciPy issue, the file is modified manually to add the libs to the path.

Hence I am under the impression that it is not necessarily an Anaconda issue but something has changed along the way, that is maybe, Python3.8 related.


Discussion:
Python 3.8 on windows no longer searches `os.environ['PATH']` for DLLs, you must use the new [os.add_dll_directory](https://docs.python.org/3/library/os.html#os.add_dll_directory) function instead. 

The code in numpy (and very recently in scipy) works around this by [generating a `_distributor_init.py`](https://github.com/numpy/numpy/blob/v1.17.4/tools/openblas_support.py#L140) file that preloads dependent DLLs by name. We chose this solution since we needed to release a fix while CPython worked out the `os.add_dll_directory` interface. Now that version 3.8 is released, perhaps we should revisit the code you pointed to, and add a path for 3.8+ behaviour. 
Indeed changing to `os.add_dll_directory()` makes the SciPy import error vanish. Though I can't explain why Python 3.7 also fails in the linked issue. 

I'll propose that fix on the SciPy side. NumPy side seems a bit more involved.

Resolving patch:
diff --git a/numpy/distutils/misc_util.py b/numpy/distutils/misc_util.py
--- a/numpy/distutils/misc_util.py
+++ b/numpy/distutils/misc_util.py
@@ -2281,8 +2281,11 @@ def generate_config_py(target):
             extra_dll_dir = os.path.join(os.path.dirname(__file__), '.libs')
 
             if sys.platform == 'win32' and os.path.isdir(extra_dll_dir):
-                os.environ.setdefault('PATH', '')
-                os.environ['PATH'] += os.pathsep + extra_dll_dir
+                if sys.version_info >= (3, 8):
+                    os.add_dll_directory(extra_dll_dir)
+                else:
+                    os.environ.setdefault('PATH', '')
+                    os.environ['PATH'] += os.pathsep + extra_dll_dir
 
             """))
 


Test patch:
Repository: numpy/numpy

Issue:
np.clip: change in precedence between minimum and maximum when maximum < minimum
Greetings!

First, thanks to the NumPy community for your efforts.

Second, In NumPy 1.16.5 I observe the following:

```python
>>> import numpy as np
>>> np.clip(2, 3, 0)
3
```

In NumPy 1.17.4, I get a different result:

```python
>>> import numpy as np
>>> np.clip(2, 3, 0)
0
```
I see that the difference has to do with which constraint gets precedence. Was this an intentional change in precedence then?


### Reproducing code example:

```python
import numpy as np
assert np.clip(2, 3, 0), 3
```

### Numpy/Python version information:

```python
>>> import sys, numpy; print(numpy.__version__, sys.version)
1.17.4 3.7.4 (default, Dec  3 2019, 11:37:16) 
[GCC 5.4.0 20160609]
```



Discussion:
As from the documentation of the function:
`No check is performed to ensure ``a_min < a_max``.`
Thanks for your response. I did see that. But the docs also say that "Equivalent to but faster than `np.maximum(a_min, np.minimum(a, a_max))`" These are no longer equivalent:

```python
>>> np.maximum(3, np.minimum(2, 0))
3
>>> np.clip(2, 3, 0)
0
```
Sounds like the doc is wrong.

Note that in the past the behavior was not as simple as you make it out to be - I believe the behavior swapped if you make the inputs arrays rather than scalars
Marking it as documentation, because at the moment I do not feel that we should undo the general clip changes. But if more concerns come up, I may change my mind.
For reference, #12519 was the change to `clip`
We knew that some of this stuff was going to happen, right? I remember a lot of confusing back-and-forth with the `hypothesis` tests & it was just really hard to get everything perfect for pathological corner cases & move forward. 

Some people also wanted an `Exception` raised because it was a little crazy to deal with `min > max`, but then performance concerns & can't easily put the handling in the inner loops and so on.

Eric can correct me if I'm wrong, but I believe the broader motivation was Travis' proposal: https://github.com/numpy/numpy/issues/12514

So maybe change in behavior for pathological cases was considered "ok" on balance to empower that broader improvent to NumPy?
Many thanks for considering this issue and providing the background to the change.

(FYI: I only noticed the change as I happened to have a StaticFrame test that was exercising the condition of maximum less than minimum.)


Resolving patch:
diff --git a/numpy/core/fromnumeric.py b/numpy/core/fromnumeric.py
--- a/numpy/core/fromnumeric.py
+++ b/numpy/core/fromnumeric.py
@@ -2033,7 +2033,8 @@ def clip(a, a_min, a_max, out=None, **kwargs):
     is specified, values smaller than 0 become 0, and values larger
     than 1 become 1.
 
-    Equivalent to but faster than ``np.maximum(a_min, np.minimum(a, a_max))``.
+    Equivalent to but faster than ``np.maximum(a_min, np.minimum(a, a_max))``
+    assuming ``a_min < a_max``.
     No check is performed to ensure ``a_min < a_max``.
 
     Parameters


Test patch:
Repository: numpy/numpy

Issue:
Remove int_asbuffer
On python 3, `int_asbuffer`:

* Checks to see if dereferencing the address would segfault
* Throws `NotImplementedError` if not

I don't think it is worth keeping around.


Discussion:

Resolving patch:
diff --git a/numpy/core/multiarray.py b/numpy/core/multiarray.py
--- a/numpy/core/multiarray.py
+++ b/numpy/core/multiarray.py
@@ -33,7 +33,7 @@
     'digitize', 'dot', 'dragon4_positional', 'dragon4_scientific', 'dtype',
     'empty', 'empty_like', 'error', 'flagsobj', 'flatiter', 'format_longfloat',
     'frombuffer', 'fromfile', 'fromiter', 'fromstring', 'inner',
-    'int_asbuffer', 'interp', 'interp_complex', 'is_busday', 'lexsort',
+    'interp', 'interp_complex', 'is_busday', 'lexsort',
     'matmul', 'may_share_memory', 'min_scalar_type', 'ndarray', 'nditer',
     'nested_iters', 'normalize_axis_index', 'packbits',
     'promote_types', 'putmask', 'ravel_multi_index', 'result_type', 'scalar',
diff --git a/numpy/core/numeric.py b/numpy/core/numeric.py
--- a/numpy/core/numeric.py
+++ b/numpy/core/numeric.py
@@ -15,7 +15,7 @@
     WRAP, arange, array, broadcast, can_cast, compare_chararrays,
     concatenate, copyto, dot, dtype, empty,
     empty_like, flatiter, frombuffer, fromfile, fromiter, fromstring,
-    inner, int_asbuffer, lexsort, matmul, may_share_memory,
+    inner, lexsort, matmul, may_share_memory,
     min_scalar_type, ndarray, nditer, nested_iters, promote_types,
     putmask, result_type, set_numeric_ops, shares_memory, vdot, where,
     zeros, normalize_axis_index)
@@ -50,7 +50,7 @@
 __all__ = [
     'newaxis', 'ndarray', 'flatiter', 'nditer', 'nested_iters', 'ufunc',
     'arange', 'array', 'zeros', 'count_nonzero', 'empty', 'broadcast', 'dtype',
-    'fromstring', 'fromfile', 'frombuffer', 'int_asbuffer', 'where',
+    'fromstring', 'fromfile', 'frombuffer', 'where',
     'argwhere', 'copyto', 'concatenate', 'fastCopyAndTranspose', 'lexsort',
     'set_numeric_ops', 'can_cast', 'promote_types', 'min_scalar_type',
     'result_type', 'isfortran', 'empty_like', 'zeros_like', 'ones_like',


Test patch:
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
@@ -48,7 +48,6 @@ def test_numpy_namespace():
         'fastCopyAndTranspose': 'numpy.core._multiarray_umath._fastCopyAndTranspose',
         'get_array_wrap': 'numpy.lib.shape_base.get_array_wrap',
         'get_include': 'numpy.lib.utils.get_include',
-        'int_asbuffer': 'numpy.core._multiarray_umath.int_asbuffer',
         'mafromtxt': 'numpy.lib.npyio.mafromtxt',
         'ndfromtxt': 'numpy.lib.npyio.ndfromtxt',
         'recfromcsv': 'numpy.lib.npyio.recfromcsv',
Repository: numpy/numpy

Issue:
dir(numpy) returns duplicate "testing"
<!-- Please describe the issue in detail here, and fill in the fields below -->

### Reproducing code example:

<!-- A short code example that reproduces the problem/missing feature. It should be
self-contained, i.e., possible to run as-is via 'python myproblem.py' -->

```python
import numpy as np
>>> np.__version__
'1.18.1'
>>> len(dir(np))
620
>>> np.testing
<module 'numpy.testing' from 'C:\\Python\\Python38\\lib\\site-packages\\numpy\\testing\\__init__.py'>
>>> len(dir(np))
621
>>> [i for i in dir(np) if i == "testing"]
['testing', 'testing']
```
### Error:
"testing" appears twice in dir(np)


### Numpy/Python version information:

<!-- Output from 'import sys, numpy; print(numpy.__version__, sys.version)' -->
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
>>> np.__version__
'1.18.1'


Discussion:
See a fix at https://stackoverflow.com/questions/59851684/python-duplicates-in-dir-is-it-a-bug
@pyscripter want to open a PR wih that fix (and best a test)?

Resolving patch:
diff --git a/numpy/__init__.py b/numpy/__init__.py
--- a/numpy/__init__.py
+++ b/numpy/__init__.py
@@ -218,7 +218,7 @@ def __getattr__(attr):
                                      "{!r}".format(__name__, attr))
 
         def __dir__():
-            return list(globals().keys()) + ['Tester', 'testing']
+            return list(globals().keys() | {'Tester', 'testing'})
 
     else:
         # We don't actually use this ourselves anymore, but I'm not 100% sure that


Test patch:
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
@@ -94,6 +94,12 @@ def test_import_lazy_import(name):
     assert name in dir(np)
 
 
+def test_dir_testing():
+    """Assert that output of dir has only one "testing/tester"
+    attribute without duplicate"""
+    assert len(dir(np)) == len(set(dir(np)))
+    
+
 def test_numpy_linalg():
     bad_results = check_dir(np.linalg)
     assert bad_results == {}
Repository: numpy/numpy

Issue:
Squeeze array with one element returns an array with no shape
<!-- Please describe the issue in detail here, and fill in the fields below -->

When squeezing an array that has only one element we get a non-dimensional array (instead of an array with one dimension).


### Reproducing code example:

<!-- A short code example that reproduces the problem/missing feature. It should be
self-contained, i.e., possible to run as-is via 'python myproblem.py' -->

```python
import numpy as np
arr = np.array([[1238]]).squeeze()
arr.shape
arr[0]
```

<!-- Remove these sections for a feature request -->

### Error message:
IndexError: too many indices for array

<!-- If you are reporting a segfault please include a GDB traceback, which you
can generate by following
https://github.com/numpy/numpy/blob/master/doc/source/dev/development_environment.rst#debugging -->

<!-- Full error message, if any (starting from line Traceback: ...) -->

### Numpy/Python version information:
1.16.4 3.6.8 |Anaconda custom (64-bit)| (default, Feb 21 2019, 18:30:04) [MSC v.1916 64 bit (AMD64)]

<!-- Output from 'import sys, numpy; print(numpy.__version__, sys.version)' -->




Discussion:
This is by design, the shape is `()`, ie a 0d array (wrapped scalar).

Are you looking for `arr.squeeze(axis=0)` or perhaps `arr.ravel()`?
Actually, let's reopen this as a documentation task to add an example of this behavior to the docstring

Resolving patch:
diff --git a/numpy/core/fromnumeric.py b/numpy/core/fromnumeric.py
--- a/numpy/core/fromnumeric.py
+++ b/numpy/core/fromnumeric.py
@@ -1445,7 +1445,8 @@ def squeeze(a, axis=None):
     squeezed : ndarray
         The input array, but with all or a subset of the
         dimensions of length 1 removed. This is always `a` itself
-        or a view into `a`.
+        or a view into `a`. Note that if all axes are squeezed,
+        the result is a 0d array and not a scalar.
 
     Raises
     ------
@@ -1472,6 +1473,15 @@ def squeeze(a, axis=None):
     ValueError: cannot select an axis to squeeze out which has size not equal to one
     >>> np.squeeze(x, axis=2).shape
     (1, 3)
+    >>> x = np.array([[1234]])
+    >>> x.shape
+    (1, 1)
+    >>> np.squeeze(x)
+    array(1234)  # 0d array
+    >>> np.squeeze(x).shape
+    ()
+    >>> np.squeeze(x)[()]
+    1234
 
     """
     try:


Test patch:
Repository: numpy/numpy

Issue:
FIXME in `numpy/__init__.py` related to `numpy.lib` imports
There is a FIXME comment in `numpy/__init__.py` that doesn't seem to have a corresponding issue on GitHub, at least not one that I noticed with a cursory search of the issues.

https://github.com/numpy/numpy/blob/eb167a3fe540780f397a14817f54a95333fbcc6c/numpy/__init__.py#L140-L145

There is additional code in `numpy/__init__.py` related to this FIXME:

https://github.com/numpy/numpy/blob/eb167a3fe540780f397a14817f54a95333fbcc6c/numpy/__init__.py#L178-L184

My intent is getting this into the issue tracker so that it can be discussed/documented and synced up with the code comments. If there is an existing issue that I missed, I'd recommend updating the comment in `numpy/__init__.py` to point there.


Discussion:
It was discussed when the PR was merged. I'm not sure there's much we can do about it in the short term.
This is not a bug nor an enhancement, so it's not clear we should have an issue for this.
Thanks for the additional info - even after you mentioned it, it took me a second to track down the discussion in #14454.

If attention is not desired here, it might be worthwhile to remove the comment just so potential contributors don't get hung up on it. Alternatively, if having the FIXME callout in the comment is desired, perhaps adding an additional comment along the lines of (see GH 14454 for discussion) would be good so that anyone who is curious about the comment can easily find the relevant discussion.
Looked into it some more, I think it's not urgent but indeed it would be a decent cleanup to remove the `from .lib import *` and replace it with explicit imports of everything that's imported now. That's about 220 functions, so also a pain. Actually not sure it's worth it - there's too much of a historical mess. Let's see what others think.

adding "see gh-14454 for discussion" is useful either way.
I agree - I will make that change.

FWIW I stumbled across this while trying to take a closer look at how the `np` namespace was constructed. 

Resolving patch:
diff --git a/numpy/__init__.py b/numpy/__init__.py
--- a/numpy/__init__.py
+++ b/numpy/__init__.py
@@ -141,7 +141,8 @@
     from .core import *
     from . import compat
     from . import lib
-    # FIXME: why have numpy.lib if everything is imported here??
+    # NOTE: to be revisited following future namespace cleanup.
+    # See gh-14454 and gh-15672 for discussion.
     from .lib import *
 
     from . import linalg


Test patch:
Repository: numpy/numpy

Issue:
BUG: np.copy does not work for nested np.arrays
I have a created a np.array which consists of two other np.array which do not have the same size. If I want to copy the array with np.copy, both arrays are still linked together. By the use of copy.deepcopy() there is no such issue. 

### Reproducing code example:

```python
import numpy as np 
import copy as cp 

a = np.array([1, 2, 3])
b = np.array([[3, 4, 5], [2, 4, 7]])
c = np.array([a, b])
d = np.copy(c)
e = cp.deepcopy(c)
d[1][0, 2] = 10
e[1][0, 1] = 20
print('c = ', c)
print('d = ', d)
print('e = ', e)

```
Output:
```python
c =  [array([1, 2, 3]) array([[ 3,  4, 10],
       [ 2,  4,  7]])]
d =  [array([1, 2, 3]) array([[ 3,  4, 10],
       [ 2,  4,  7]])]
e =  [array([1, 2, 3]) array([[ 3, 20,  5],
       [ 2,  4,  7]])]
```

### Numpy/Python version information:

numpy version: 1.15.4
python version: 3.6.8 |Anaconda, Inc.| (default, Dec 30 2018, 18:50:55) [MSC v.1915 64 bit (AMD64)]




Discussion:
This is by design, `np.copy()` does not attempt to copy elements in object arrays.

A note in the docs for `np.copy` that this does not perform a deep-copy of object arrays would probably be a nice idea.
I think this only happens with ragged sequences. See:

```python
In [149]: a = np.array([1, 2, 3])

In [150]: b = np.array([1, 2, 3])

In [151]: c = np.copy(np.array([a, b], dtype=object))

In [152]: d = np.copy(np.array([a, [a, a]], dtype=object))

In [153]: c[0][0] = 123

In [154]: d[0][2] = 789

In [155]: a
Out[155]: array([  1,   2, 789])

In [156]: b
Out[156]: array([1, 2, 3])

In [157]: c
Out[157]:
array([[123, 2, 3],
       [1, 2, 3]], dtype=object)

In [158]: d
Out[158]:
array([array([  1,   2, 789]),
       list([array([  1,   2, 789]), array([  1,   2, 789])])],
      dtype=object)
```

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
@@ -764,6 +764,30 @@ def copy(a, order='K', subok=False):
     >>> x[0] == z[0]
     False
 
+    Note that np.copy is a shallow copy and will not copy object
+    elements within arrays. This is mainly important for arrays
+    containing Python objects. The new array will contain the
+    same object which may lead to surprises if that object can
+    be modified (is mutable):
+
+    >>> a = np.array([1, 'm', [2, 3, 4]], dtype=object)
+    >>> b = np.copy(a)
+    >>> b[2][0] = 10
+    >>> a
+    array([1, 'm', list([10, 3, 4])], dtype=object)
+
+    To ensure all elements within an ``object`` array are copied,
+    use `copy.deepcopy`:
+
+    >>> import copy
+    >>> a = np.array([1, 'm', [2, 3, 4]], dtype=object)
+    >>> c = copy.deepcopy(a)
+    >>> c[2][0] = 10
+    >>> c
+    array([1, 'm', list([10, 3, 4])], dtype=object)
+    >>> a
+    array([1, 'm', list([2, 3, 4])], dtype=object)
+
     """
     return array(a, order=order, subok=subok, copy=True)
 


Test patch: