Skip to content

MAINT: avoid relying on np.generic.__name__ in np.dtype.name #12205

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 1 commit into from
Sep 11, 2019

Conversation

eric-wieser
Copy link
Member

dtype.name is documented as returning a "bit name" - however, we don't want to force __name__ to be a bit name, as this creates confusing collisions in the repr of the scalar types.

This should be the last refactor needed to get #10151 in.

@eric-wieser
Copy link
Member Author

This fails with:

    def test_name_dtype_subclass(self):
        # Ticket #4357
        class user_def_subcls(np.void):
            pass
>       assert_equal(np.dtype(user_def_subcls).name, 'user_def_subcls')
E       AssertionError: 
E       Items are not equal:
E        ACTUAL: 'void'
E        DESIRED: 'user_def_subcls'

Does this test make any sense?

# handle bool_, str_, etc
if name[-1] == '_':
name = name[:-1]
name = _kind_name(dtype)
Copy link
Member

Choose a reason for hiding this comment

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

I assume this change is responsible for the test failure. I assume that the _kind_name of a derived class is the same as the base class, which makes sense, so the question is whether to use the type.__name__ instead. I think that makes some sense, it seems it would be more informative anyway. More input from others would be helpful.

@eric-wieser eric-wieser self-assigned this May 11, 2019
`dtype.name` is documented as returning a "bit name" - however, we don't want to force `__name__` to be a bit name, as this creates confusing collisions in the repr of the scalar types.
@eric-wieser
Copy link
Member Author

I no longer remember why I abandoned this, test hopefully now fixed.

@mattip
Copy link
Member

mattip commented Sep 11, 2019

Tests pass. No new tests needed?

@eric-wieser
Copy link
Member Author

No behavior change here, this was just a refactor needed for 10151, where I plan to change the name attribute.

@mattip mattip merged commit f14aee7 into numpy:master Sep 11, 2019
@mattip
Copy link
Member

mattip commented Sep 11, 2019

Thanks for this piece of the puzzle

@eric-wieser eric-wieser deleted the kind-names-2 branch September 14, 2019 20:00
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.

3 participants