Skip to content

TYP: generic StringDType #28856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 1, 2025
Merged

TYP: generic StringDType #28856

merged 3 commits into from
May 1, 2025

Conversation

jorenham
Copy link
Member

ported from numpy/numtype#335


This also adds the missing na_object and coerce kwargs to StringDType.__new__

@jorenham jorenham added the 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes label Apr 28, 2025
@jorenham jorenham added this to the 2.3.0 release milestone Apr 28, 2025
@jorenham jorenham added 41 - Static typing numtype Isssue/PR related to numpy/numtype labels Apr 28, 2025
@jorenham jorenham marked this pull request as ready for review April 28, 2025 20:37
@jorenham jorenham removed the 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes label Apr 28, 2025
@ngoldbaum ngoldbaum self-assigned this Apr 29, 2025
@ngoldbaum ngoldbaum added the component: numpy.strings String dtypes and functions label Apr 29, 2025
Copy link
Member

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably needs some new typing tests too?

Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
@jorenham
Copy link
Member Author

Probably needs some new typing tests too?

It's all pretty straightforward so I didn't think it would be necessary to add additional tests for this. I figured that as long as the current type-tests involving StringDType still pass, then it's fine. Mypy primer also shows no diff.

Testing this would also be rather difficult because it involves typing.Never. If you'd do something like assert_type(StringDType().na_object, typing.Never), then mypy doesn't analyze anything that comes after that statement, because it assumes that accessing na_object: typing.Never will raise an exception. It's possible to work around that by wrapping it in a function, but it'd be a lot of effort for a rather trivial annotation.

But if you want to see some test either way, I won't mind adding some 🤷🏻

@ngoldbaum
Copy link
Member

But if you want to see some test either way, I won't mind adding some 🤷🏻

Eh, no worries.

@charris charris merged commit 01f2fec into numpy:main May 1, 2025
75 checks passed
@charris
Copy link
Member

charris commented May 1, 2025

Thanks Joren.

@jorenham jorenham deleted the numtype/335 branch May 1, 2025 18:26
MaanasArora pushed a commit to MaanasArora/numpy that referenced this pull request May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
41 - Static typing component: numpy.strings String dtypes and functions numtype Isssue/PR related to numpy/numtype
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy