8000 ENH: fix printing structured dtypes with a non-legacy dtype member by ngoldbaum · Pull Request #24758 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

ENH: fix printing structured dtypes with a non-legacy dtype member #24758

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 2 commits into from
Sep 26, 2023

Conversation

ngoldbaum
Copy link
Member

Fixes numpy/numpy-user-dtypes#87

See related PR #23047 which fixed dtype.name in a similar way.

I don't know offhand if structured dtypes are broken in other ways, but basic testing indicates that it seems to work:

In [1]: import numpy as np

In [2]: from stringdtype import StringDType

In [3]: arr = np.array(
   ...:     [("Rex", 9, 81.0), ("Fido", 3, 27.0)],
   ...:     dtype=[("name", StringDType()), ("age", "i4"), ("weight", "f4")],
   ...: )

In [4]: arr[0][0]
Out[4]: 'Rex'

In [5]: type(arr[0][0])
Out[5]: str

In [6]: arr.dtype
Out[6]: dtype([('name', 'StringDType128'), ('age', '<i4'), ('weight', '<f4')])

In [7]: print(arr.astype(np.dtype([("name", "<U10"), ("age", "<i4"), ("weight", "<f4")])))
[('Rex', 9, 81.) ('Fido', 3, 27.)]

In [8]: arr.astype(np.dtype([("name", "<U10"), ("age", "<i4"), ("weight", "<f4")]))[0][0]
Out[8]: np.str_('Rex')


@ngoldbaum
Copy link
Member Author

@seberg think this is OK? I know you weren’t very happy about adding explicit comparisons with the null kind character but this pattern is already used in a similar way elsewhere in this file and can be refactored once we have a better way to spell this check.

@@ -126,6 +126,9 @@ def _scalar_str(dtype, short):
else:
return "'%sU%d'" % (byteorder, dtype.itemsize / 4)

elif dtype.kind == '\x00':
return f"'{byteorder}{type(dtype).__name__}{dtype.itemsize * 8}'"
Copy link
Member

Choose a reason for hiding this comment

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

Yes, I am fine with this, although don't have _legacy now to do this?

I am confused about this type of string, though, can't we use the repr? {byteorder}{TypeName}{itemsize} doesn't need to be much of a reasonable repr?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm fine with just using the repr here and in the other path, I agree that the bitsize isn't particularly useful and if someone thinks it's worth including they can include it in the repr. Mind if I take care of that in a followup?

Copy link
Member

Choose a reason for hiding this comment

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

Sure, I am fine with that, since its all in flux somewhat alpha stage anyway. Thanks @ngoldbaum lets just put it in.

dt = np.dtype([("id", int), ("value", SF(0.5))])
# repr of structured dtypes need special handling because the
# implementation bypasses the object repr
assert "('value', '_ScaledFloatTestDType64')" in repr(dt)
Copy link
Member
@seberg seberg Sep 25, 2023

Choose a reason for hiding this comment

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

A bit confusing, I woul;d have thout if the test above does SF(1.).name == "_ScaledFloatTestDType64" we get _ScaledFloatTestDType6464 here :).

EDIT: Ahh, nvm. I guess this and the above are actually very similar in what they use/define as "name". Hmmmm...

@seberg seberg merged commit 26d15ff into numpy:main Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

stringdtype: problem displaying a structured array containing a StringDType
2 participants
0