8000 BUG: dtype reprs are misleading · Issue #22920 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

BUG: dtype reprs are misleading #22920

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.

Sign up for GitHub

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

Jump to bottom
Closed
ngoldbaum opened this issue Jan 3, 2023 · 3 comments
Closed

BUG: dtype reprs are misleading #22920

ngoldbaum opened this issue Jan 3, 2023 · 3 comments
Labels
00 - Bug

Comments

@ngoldbaum
Copy link
Member

Describe the issue:

Currently dtype class reprs indicate that you can go through __getitem__ on np.dtype to get a dtype class, but since #19879, doing np.dtype[some_type] returns a types.GenericAlias instance rather than a dtype class.

Reproduce the code example:

import numpy as np
dtype = np.dtype('float32')
print(f"{dtype = }")

dtype_type = type(dtype)
print(f"{dtype_type = }")

type_of_dtype_type = type(dtype_type)
print(f"{type_of_dtype_type = }")

dtype_getitem = np.dtype[np.float32]
print(f"{dtype_getitem = }")

type_of_dtype_getitem = type(dtype_getitem)
print(f"{type_of_dtype_getitem = }")

Error message:

# no error message, but the script currently prints:

dtype = dtype('float32')
dtype_type = <class 'numpy.dtype[float32]'>
type_of_dtype_type = <class 'numpy._DTypeMeta'>
dtype_getitem = numpy.dtype[numpy.float32]
type_of_dtype_getitem = <class 'types.GenericAlias'>

Runtime information:

>>> import sys, numpy; print(numpy.__version__); print(sys.version)
1.25.0.dev0+264.g664623126
3.10.8 (main, Nov  8 2022, 10:29:11) [GCC 11.3.0]
>>> print(numpy.show_runtime())
WARNING: `threadpoolctl` not found in system! Install it by `pip install threadpoolctl`. Once installed, try `np.show_runtime` again for more detailed build information
[{'numpy_version': '1.25.0.dev0+264.g664623126',
  'python': '3.10.8 (main, Nov  8 2022, 10:29:11) [GCC 11.3.0]',
  'uname': uname_result(system='Linux', node='rous', release='5.15.0-56-generic', version='#62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022', machine='x86_64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3',
                                'SSE41',
                                'POPCNT',
                                'SSE42',
                                'AVX',
                                'F16C',
                                'FMA3',
                                'AVX2'],
                      'not_found': ['AVX512F',
                                    'AVX512CD',
                                    'AVX512_KNL',
                                    'AVX512_KNM',
                                    'AVX512_SKX',
                                    'AVX512_CLX',
                                    'AVX512_CNL',
                                    'AVX512_ICL']}}]
None

Context for the issue:

I think the API the reprs suggest would be nice if it returned dtype classes rather than a GenericAlias, which isn't useful for working with dtypes at runtime.

I have no idea if returning the classes rather than GenericAlias is a problem for the python static types. If it is an issue then the dtype reprs should probably be changed to something that will generate a dtype class, even if it ends up being ugly (e.g. type(np.dtype(np.float32))) instead of np.dtype[np.float32]).
@mhvk
Copy link
Contributor
mhvk commented Jan 3, 2023

I think np.dtype[...] goes through __class_getitem__, which is mostly meant for typing. Of course, that doesn't change the argument for not using it in the __repr__!

@seberg
Copy link
Member
seberg commented Jan 3, 2023

Basically, the reason why we got here is that:

  1. I wanted a way to expose np.descr.from_scalar_type()
  2. wasn't sure how best to name the new classes and where to put them.

Using the np.dtype[...] syntax seemed neat, but appears to clash with the use in typing. So basically I think we just need to figure out where to put the classes, unless the clash with typing can be resolved easily (and I am not even sure it should be).

@ngoldbaum
Copy link
Member Author

This is fixed now that dtype classes live in numpy.dtypes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seberg @mhvk @ngoldbaum
0