Skip to content
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

BUG: error in string array generated with arange function #22055

Closed
m-aguena opened this issue Jul 29, 2022 · 7 comments
Closed

BUG: error in string array generated with arange function #22055

m-aguena opened this issue Jul 29, 2022 · 7 comments
Labels

Comments

@m-aguena
Copy link

Describe the issue:

Arrays created with np.arange(n, dtype=str) for n>2 raise an error.

Reproduce the code example:

import numpy as np
np.arange(3, dtype=str)

Error message:

File "<stdin>", line 1, in <module>
ValueError: no fill-function for data-type.

NumPy/Python version information:

1.23.1, 3.10.4 (main, Mar 31 2022, 08:41:55) [GCC 7.5.0]

@seberg
Copy link
Member

seberg commented Jul 30, 2022

I am not quite convinced that arange on strings make much sense. Maybe you would want np.arange("a", "z") to work? You can cast to string later on with .astype(str).
It may be a bit weird that n==1 apparently works. But generally I would lean towards closing it as correct (with the caveat that maybe we should disallow the n==1 case as well.

@seberg seberg added the 57 - Close? Issues which may be closable unless discussion continued label Jul 30, 2022
@rkern
Copy link
Member

rkern commented Jul 30, 2022

I concur.

@m-aguena
Copy link
Author

I agree with this solution, as long as there is consistency (n==2 also works btw).

@ddasilva
Copy link
Contributor

ddasilva commented Aug 7, 2022

I'm trying to work on this by adding a check to the multiarraymodule.c function for arange() which throws a TypeError if the dtype is string. I'm stuck trying to figure out how to check if PyArray_Descr *typecode is a string. Any advice?

@ddasilva
Copy link
Contributor

ddasilva commented Aug 7, 2022

Nevermind, figured it out. PR coming soon..

@rgommers rgommers removed the 57 - Close? Issues which may be closable unless discussion continued label Nov 21, 2022
@rgommers
Copy link
Member

PR ready, so that should just be reviewed (seems like not much work) - so removed the Close? label.

@seberg
Copy link
Member

seberg commented Nov 22, 2022

PR wasn't correctly linked, closing.

@seberg seberg closed this as completed Nov 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants