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
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion numpy/core/_dtype.py
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,9 @@ def _scalar_str(dtype, short):
else:
return "'%sU%d'" % (byteorder, dtype.itemsize / 4)

elif not type(dtype)._legacy:
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.


# unlike the other types, subclasses of void are preserved - but
# historically the repr does not actually reveal the subclass
elif issubclass(dtype.type, np.void):
Expand Down Expand Up @@ -350,8 +353,9 @@ def _name_get(dtype):
# user dtypes don't promise to do anything special
return dtype.type.__name__

if dtype.kind == '\x00':
if not type(dtype)._legacy:
name = type(dtype).__name__

elif issubclass(dtype.type, np.void):
# historically, void subclasses preserve their name, eg `record64`
name = dtype.type.__name__
Expand Down
6 changes: 6 additions & 0 deletions numpy/core/tests/test_custom_dtypes.py
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,12 @@ def test_repr(self):
def test_dtype_name(self):
assert SF(1.).name == "_ScaledFloatTestDType64"

def test_sfloat_structured_dtype_printing(self):
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...


@pytest.mark.parametrize("scaling", [1., -1., 2.])
def test_sfloat_from_float(self, scaling):
a = np.array([1., 2., 3.]).astype(dtype=SF(scaling))
Expand Down
0