DEP: deprecate numpy.typing.NBitBase#28884
Conversation
This comment has been minimized.
This comment has been minimized.
|
I'm a sphinx noob, so I had Claude write the release note. Content-wise it looks fine to me, but there might be sphinx issues or something 🤷🏻. |
c404985 to
8176a27
Compare
|
This comment has been minimized.
This comment has been minimized.
8176a27 to
c2fb472
Compare
c2fb472 to
72fcaa9
Compare
|
Diff from mypy_primer, showing the effect of this PR on type check results on a corpus of open source code: pandas (https://github.com/pandas-dev/pandas)
+ pandas/_typing.py:91: error: Unused "type: ignore" comment [unused-ignore]
|
|
Do you consider this ready? I note several runs of |
Ah yea sorry about that, I was |
|
Thanks Joren, let's see how it goes. The vibe coding is an interesting experiment. Is there anyway to control the line length? |
Hmmm, I guess you could try including it in the prompt 🤷🏻? |
numpy.typing.NBitBaseis intended to be used as e.g.This will lead to problems for
float64andcomplex128, which were changed into concrete subtypes offloatingandcomplexfloatingin NumPy 2.2. That means that e.g.floating[_64Bit]is no longer assignable tofloat64, causing type-checkers to rejectx: float64 = f(complex128(1)). This defeats its purpose, and should therefore no longer be used.The general alternative is to use
typing.overload:And even though it has gotten more verbose, it requires less mental to interpret.
In situations where the input scalar type is the same as the output type, there's a simpler alternative:
Old:
New:
This also makes the code more readable, IMO.
Note that at the moment,
float32is assignable tofloating[_32Bit], because it is defined as a type alias, as opposed to a proper subtype. In NumType this has already been fixed (i.e. it's incorrect) for all scalar types.