API: Add `np.long` and `np.ulong` by mtsokol · Pull Request #24922 · numpy/numpy

mtsokol · 2023-10-13T13:29:53Z

Connected to #24224.

In this minimal PR I introduced np.long and np.ulong only, without interfering with np.int_ and np.uint (the latter pair is an alias from now here but they map to NPY_LONG/NPY_ULONG exactly as before).

seberg · 2023-10-13T13:43:44Z

Thanks, didn't realize it would be quite this small. Should probably add it to the stubs also? (I know very minimal, and doesn't help with the diff on the other PR.)

Maybe we can get this in quickly, then see if there are more small adaptations where np.long is clearly what we want to split out from the other PR (although I don't think it is terribly big, unfortunately the main moving parts are hard to split out).

mtsokol · 2023-10-13T13:46:43Z

Sure! Right, mypy stubs are missing.

numpy/core/_type_aliases.py

eric-wieser · 2023-10-13T14:03:13Z

doc/release/upcoming_changes/24922.new_feature.rst

+`numpy.long` and `numpy.ulong` have been reintroduced as a direct
+mapping to C's ``long`` and ``unsigned long`` types.


"reintroduced" suggests they have the same meaning as before they were removed, but this is not the case.

Maybe we can just remove it and say: ... added as NumPy integers mapping to C's long and unsigned long. Prior to NumPy 1.24 np.long was an alias to Python's int.

It was actually deprecated at the time already I think. (Ignoring that it was Python long on Python 2, and then actually had the long long meaning in dtype(...), I think it was just int after that.)

Sure, I updated it accordingly.

eric-wieser · 2023-10-13T14:04:34Z

numpy/_typing/_char_codes.py

+_UIntCodes = Literal["uint", "L", "=L", "<L", ">L"]
+_ULongCodes = Literal["ulong"]


Suggested change

_UIntCodes = Literal["uint", "L", "=L", "<L", ">L"]

_ULongCodes = Literal["ulong"]

_ULongCodes = Literal["ulong", "uint", "L", "=L", "<L", ">L"]

I think that "uint" should still be associated with np.uint. I also wanted to make this PR minimal, just reintroduce np.long. WDYT?

These should be considered as aliases for the same thing, so I don't see why we'd want to give them a different typecode.

There is a tricky thing with the follow up, but right now, ulong is a correct type code for uint, so renaming it doesn't really matter. Maybe it actually makes sense to make: _UIntCodes = _ULongCodes?

What I am unclear about is what needs to change if we change this to _UIntCodes = _UIntpCodes later. @BvB93 gave a diff in the PR doing that, but it is not quite clear to me that it is complete now.

I updated it so now:

_ULongCodes = Literal["ulong", "uint", "L", "=L", "<L", ">L"] _UIntCodes = _ULongCodes

(same for int/long)

seberg · 2023-10-16T13:54:20Z

Ok, let me put this in. I don't think this is the final word on typing here. Declaring it as an alias only is fine, but only of limited help for now and the alias isn't even used, yet.

In practice almost all (maybe even all) places should just use Long now.
The same goes for almost all uses of np.int_, although I suspect there are may be a few exception and maybe places where the None overload should move or use the _IntCodes alias explicitly.

@mtsokol do you want to follow up with that move? I am pretty sure changing what _IntCodes is here now without renaming practically everything is wrong. If this ends up renaming everything, then someone can eventually delete it again.

mtsokol · 2023-10-16T14:02:42Z

@mtsokol do you want to follow up with that move? I am pretty sure changing what _IntCodes is here now without renaming practically everything is wrong. If this ends up renaming everything, then someone can eventually delete it again.

Sure! I will take care of it.

BvB93 · 2023-10-16T14:55:51Z

Right, as (u)int is now merely a (u)intp alias I don't think there's much of a reason to keep the _(U)IntCodes type around (especially since the relevant string literals have been repurposed for _(U)LongCodes anyway).

In practice almost all (maybe even all) places should just use Long now.

This might be good to check, yes. There are a number of functions that always return int_-based dtypes as of 1.26, e.g. busday_count, but it's not entirely clear to me which ones now map to long and which ones to intp/int_ (wouldn't surprise me if it's a mix of both in reality...).

seberg · 2023-10-16T15:47:06Z

I think it is safe to say that they should all map to int_ now, unless the input is typed as "long". The only exception will be mtrand.
If there is a weird corner case where this turns out to be wrong, I am willing to shrug it off as a bug.

Hi! This PR addresses #11093. It skips `np.bool` and `np.long` replacements as both of these names were reintroduced in NumPy 2.0 with a different meaning (numpy/numpy#24922, numpy/numpy#25080). With this change `NPY001` will no longer conflict with `NPY201`. For projects using NumPy 1.x `np.bool` and `np.long` has been deprecated and removed long time ago, and accessing them yields an informative error message.

API: Add np.long and np.ulong

77919ed

mtsokol self-assigned this Oct 13, 2023

github-actions bot added the 30 - API label Oct 13, 2023

mtsokol added Numpy 2.0 API Changes 30 - API and removed 30 - API labels Oct 13, 2023

eric-wieser reviewed Oct 13, 2023

View reviewed changes

numpy/core/_type_aliases.py Show resolved Hide resolved

mtsokol force-pushed the introduce-np-long branch from 56177e5 to b68854d Compare October 13, 2023 14:02

eric-wieser reviewed Oct 13, 2023

View reviewed changes

Add typing for long. Add release note

1560830

mtsokol force-pushed the introduce-np-long branch from b68854d to 1560830 Compare October 13, 2023 14:13

mtsokol added 2 commits October 13, 2023 18:20

Update release note

5d40081

Apply review changes

14da3e2

mtsokol requested a review from seberg October 16, 2023 11:48

seberg merged commit 018c24d into numpy:main Oct 16, 2023

mtsokol deleted the introduce-np-long branch October 16, 2023 14:00

This was referenced Oct 30, 2023

DOC: np.long doesn't show up in scalar reference doc #25015

Closed

MAINT: Adjust typing for readded np.long #25039

Merged

mtsokol mentioned this pull request Jun 4, 2024

Update NPY001 rule for NumPy 2.0 astral-sh/ruff#11735

Merged

		`numpy.long` and `numpy.ulong` have been reintroduced as a direct
		mapping to C's ``long`` and ``unsigned long`` types.

		_UIntCodes = Literal["uint", "L", "=L", "<L", ">L"]
		_ULongCodes = Literal["ulong"]

	_UIntCodes = Literal["uint", "L", "=L", "<L", ">L"]
	_ULongCodes = Literal["ulong"]
	_ULongCodes = Literal["ulong", "uint", "L", "=L", "<L", ">L"]

Uh oh!

Conversation

mtsokol commented Oct 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seberg commented Oct 13, 2023

Uh oh!

mtsokol commented Oct 13, 2023

Uh oh!

Uh oh!

eric-wieser Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

seberg Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

mtsokol Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

eric-wieser Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

mtsokol Oct 13, 2023 • 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!

eric-wieser Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

seberg Oct 13, 2023

Choose a reason for hiding this comment

Uh oh!

mtsokol Oct 16, 2023 • 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!

seberg commented Oct 16, 2023

Uh oh!

mtsokol commented Oct 16, 2023

Uh oh!

BvB93 commented Oct 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seberg commented Oct 16, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mtsokol commented Oct 13, 2023 •

edited

Loading

mtsokol Oct 13, 2023 •

edited

Loading

mtsokol Oct 16, 2023 •

edited

Loading

BvB93 commented Oct 16, 2023 •

edited

Loading