BUG: np.take out dtype by himanow · Pull Request #30615 · numpy/numpy

himanow · 2026-01-09T07:15:50Z

Description

This PR addresses the issue in np.take where an error was raised when input and output dtypes were different during casting.

Key changes:

Allows 'same-kind' casting to proceed in np.take.
Emits a DeprecationWarning for other casting types to maintain backward compatibility while signaling future changes.

This is my first contribution to NumPy, so I'm opening this as a draft to ensure the implementation and formatting align with the project's standards. I'd appreciate any feedback on the code or the CI results.

Fixes

Closes #25588

himanow · 2026-01-11T10:10:29Z

I rebased my branch onto the latest main, and all CI/CD checks are now passing

seberg · 2026-01-12T10:05:54Z

-            raise AssertionError("compress with an out which cannot be "
-                                 "safely casted should not return "
-                                 "successfully")
+            assert_equal(b, np.array([[1.0], [3.0]]))


Can you please explain this change?

The compress method uses PyArray_TakeFrom internally. Since it no longer raises an error after my changes, I have updated the test to verify that the output values match the expected results.

OK, I guess this is fine to generalize. We may want to tighten the casting from same-kind at some point, but I don't think we have to worry about it now.

seberg · 2026-01-12T10:06:12Z

+        assert_array_equal(a[indices], out)
+        diffrent_dtype_out = np.zeros_like(indices, dtype=np.uint32)
+        with pytest.warns(DeprecationWarning):
+            np.take(a, indices, out=diffrent_dtype_out)


Please move this test to test_deprecations and use the pattern used there.

Fixed in commit 0029b81. Could you please check if the implementation and coding style are correct?

seberg · 2026-01-12T10:07:06Z

+                            "Implicit casting of output to a different kind is "
+                            "deprecated. "
+                            "In a future version, this will result in an error. Please "
+                            "ensure the output has the same-kind type as the input.") <


Please add the comments we usually add to say when the deprecation happened (before it) and also inside the deprecation itself, such as (deprecated NumPy 2.5).

The last sentence feels like unnecessary to me. (I should think once more if we shouldn't just use safe casting, although then one might be tempted to ask for a casting= kwarg.)

Fixed in commit 0029b81. I removed the last sentence.

seberg · 2026-01-12T10:11:25Z

@@ -311,7 +311,25 @@ PyArray_TakeFrom(PyArrayObject *self0, PyObject *indices0, int axis,
        }
        dtype = PyArray_DESCR(self);
        Py_INCREF(dtype);


This needs cleaning up, you are inserting code but that code interacts closely with this so you can't insert code between these two lines.
I.e. the dtype reference can be lost on error.

Fixed in 0029b81. Is it safe to insert code between dtype = PyArray_DESCR(self); and Py_INCREF(dtype);? Also, is the line Py_INCREF(out_dtype); unnecessary or redundant here?

seberg · 2026-01-12T10:14:11Z

+                }
+            }
+            flags |= NPY_ARRAY_FORCECAST;
+            obj = (PyArrayObject *)PyArray_FromArray(out, dtype, flags);


This is the exact same code as the first branch, except for a flag that is irrelevant in the first branch.

Fixed in commit 0029b81.

himanow · 2026-01-17T07:47:17Z

Thank you for the detailed feedback. I have pushed the fixes in the latest commit.

seberg

Thanks a few nits, mainly the refcount addition is incorrect and I think it would be good to add a test that goes across kind boundaries (if you looked at it the other way).

seberg · 2026-01-27T13:45:37Z

+            flags |= NPY_ARRAY_FORCECAST;
+        }
        Py_INCREF(dtype);
+        Py_INCREF(out_dtype);


This incref isn't necessary here.

Fixed in 6f40af4.

seberg · 2026-01-27T13:46:12Z

+                if (DEPRECATE(
+                            "Implicit casting of output to a different kind is "
+                            "deprecated. "
+                            "In a future version, this will result in an error. (Deprecated NumPy 2.5)") <


Can you format this a bit prettier? (e.g. start at smaller indent, don't break the line when there is no \n anyway.

Fixed in 6f40af4.

seberg · 2026-01-27T13:46:21Z

        dtype = PyArray_DESCR(self);
+        out_dtype = PyArray_DESCR(out);
+        if (dtype != out_dtype) {
+            /*Deprecated NumPy 2.5, 2026-01*/


Suggested change

/*Deprecated NumPy 2.5, 2026-01*/

/* Deprecated NumPy 2.5, 2026-01 */

"Updated as suggested."

seberg · 2026-01-27T13:47:49Z

+        out_dtype = PyArray_DESCR(out);
+        if (dtype != out_dtype) {
+            /*Deprecated NumPy 2.5, 2026-01*/
+            if (PyArray_CanCastTypeTo(dtype, out_dtype, NPY_SAME_KIND_CASTING) == 0) {


Most code uses !PyArray_... for this type of pattern, so I would stick to it here too. (The < 0 is very common for errors.)

Fixed in 6f40af4. I've updated this to follow the !PyArray_... pattern.

seberg · 2026-01-27T13:50:29Z

-            raise AssertionError("compress with an out which cannot be "
-                                 "safely casted should not return "
-                                 "successfully")
+            assert_equal(b, np.array([[1.0], [3.0]]))


OK, I guess this is fine to generalize. We may want to tighten the casting from same-kind at some point, but I don't think we have to worry about it now.

seberg · 2026-01-27T13:51:57Z

+
+        self.assert_deprecated(
+            np.take, args=(a, indices), kwargs={"out": diffrent_dtype_out}
+        )


different_dtype_out or just shorten (small typo). This is good as is, but while I wrote this args/kwargs, I actually like the pattern we use a lot more to just use a lambda, i.e. passing lambda: np.take(a, indices, out=out) (it even ends up shorter!)

Fixed in 6f40af4. I've renamed the variable to different_dtype_out. I also switched to the lambda pattern as you suggested—it definitely looks much cleaner and more concise.

himanow · 2026-02-01T06:48:45Z

Thanks for the thorough review. I’ve updated the PR and addressed each comment.

himanow · 2026-02-23T13:00:18Z

I have resolved the merge conflicts and rebased the branch onto the latest main.
CI is still in progress, but the PR is ready for further review.
I will keep monitoring the test results. Thank you.

himanow · 2026-03-15T10:45:52Z

Hi @seberg , sorry for the ping, but I'm just checking in to see if there's anything else I should update for this PR. I’d appreciate any feedback when you have a moment"

seberg · 2026-03-17T16:04:59Z

Sorry, I forgot about this. We have conflicts now, and it would make sense to add a very brief (single bullet point is OK) release note for the new deprecation.
But yeah, I think this is good and I can make sure to just do those follow ups myself some time.

himanow · 2026-03-20T13:58:05Z

Thank you! I appreciate you taking care of the conflicts and the release note. I look forward to it.

Previously, an error was raised when the input and output dtypes were different during casting. This change allows 'same-kind' casting to proceed while issuing a DeprecationWarning for other casting types to maintain backward compatibility while signaling future changes. Closes numpy#25588

github-actions Bot added the 00 - Bug label Jan 9, 2026

This comment was marked as outdated.

Sign in to view

himanow force-pushed the take_out_dtype branch from 792839e to 26d014a Compare January 11, 2026 08:58

jorenham marked this pull request as ready for review January 11, 2026 10:12

seberg reviewed Jan 12, 2026

View reviewed changes

seberg reviewed Jan 27, 2026

View reviewed changes

himanow force-pushed the take_out_dtype branch from 6f40af4 to e0a9dfd Compare February 23, 2026 12:41

seberg added this to the 2.5.0 Release milestone Mar 17, 2026

himanow and others added 5 commits March 24, 2026 16:27

BUG: small adjustments after draft PR

abde45c

BUG: address review comments for np.take

dfffbcb

BUG:Address review comments

f808024

Fixup tests, formatting and add release note

ef33a6d

seberg force-pushed the take_out_dtype branch from e0a9dfd to ef33a6d Compare March 24, 2026 15:29

seberg merged commit e87d0e0 into numpy:main Mar 24, 2026
79 checks passed

acosmicflamingo mentioned this pull request Jul 13, 2026

Fix tests for NumPy 2.5 (take out= dtype, numpy.fix deprecation) cupy/cupy#10094

Open

	/Deprecated NumPy 2.5, 2026-01/
	/* Deprecated NumPy 2.5, 2026-01 */

Uh oh!

Uh oh!

Conversation

himanow commented Jan 9, 2026

Description

Fixes

Uh oh!

This comment was marked as outdated.

himanow commented Jan 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

himanow Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

himanow Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

himanow Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

himanow commented Jan 17, 2026

Uh oh!

seberg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

himanow commented Feb 1, 2026

Uh oh!

himanow commented Feb 23, 2026

Uh oh!

himanow commented Mar 15, 2026

Uh oh!

seberg commented Mar 17, 2026

Uh oh!

himanow commented Mar 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

himanow Jan 17, 2026 •

edited

Loading

himanow Jan 17, 2026 •

edited

Loading

himanow Jan 17, 2026 •

edited

Loading