Expand dtype accessors

[oleksandr-pavlyk]

Description

Added explicit constructor for py::dtype from type number. Also added accessor to retrieve the type_num field of the struct.

While at it, added other accessors.

Added tests.

Suggested changelog entry:

dtype constructor from type number added, accessors corresponding to Python API ``dtype.num``, ``dtype.byteorder``, ``dtype.flags`` and ``dtype.alignment`` added.

[rwgk]

Nice, thanks!

[oleksandr-pavlyk]

Failures are due to error while cloning the Eigen repo.

[Skylion007]

Actually, now that it's merged, not sure the new ctor is really necessary. Wouldn't

dtype::from_args(py::int_(typenum))

have worked? @oleksandr-pavlyk ?

[oleksandr-pavlyk]

Actually, since py::from_args is equivalent of calling np.dtype, it dos not work:

In [2]: np.dtype(12)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-dea73ed57aec> in <module>
----> 1 np.dtype(12)

TypeError: Cannot interpret '12' as a data type

In fact modifying the test file:

diff --git a/tests/test_numpy_dtypes.cpp b/tests/test_numpy_dtypes.cpp
index 7de36f2f..8ed6ff8d 100644
--- a/tests/test_numpy_dtypes.cpp
+++ b/tests/test_numpy_dtypes.cpp
@@ -291,7 +291,7 @@ py::list test_dtype_ctors() {
     list.append(py::dtype(names, formats, offsets, 20));
     list.append(py::dtype(py::buffer_info((void *) 0, sizeof(unsigned int), "I", 1)));
     list.append(py::dtype(py::buffer_info((void *) 0, 0, "T{i:a:f:b:}", 1)));
-    list.append(py::dtype(py::detail::npy_api::NPY_DOUBLE_));
+    list.append(py::dtype::from_args(py::int_(static_cast<int>(py::detail::npy_api::NPY_DOUBLE_))));
     return list;
 }

and running raises the same error.

Even if this worked, it would still be less efficient that the added ctor, since the argument Python object needs to be constructed.

[Skylion007]

I am just wondering if these is a less ambiguous way to build that ctor. Perhaps we could have it take an enum instead of an int or something along those lines? Or maybe it would make more sense to have it be a static factory method. It's a bit weird for the dtype to have an int constructor as it stands currently.

Right now it's a public constructor that could only be used via an implementation detail enum, which is actually really weird. Thoughts @henryiii @rwgk ?

[Skylion007]

I am just having second thoughts about having this ctor be a part of the public API for dtypes considering the values that are used for it are themselves not public.

[oleksandr-pavlyk]

Yes, agreed, the non-public nature of type numbers has bugged me too, but I dismissed it since it is easy to #include "numpy/ndarraytypes.h", or use py::detail.

Also the exposure of num() accessor allows for use of private enums, dtype(dt.num()).

[Skylion007]

@oleksandr-pavlyk We can revisit this PR in connection to casters we design for #3858 . I'm sure once we see them sketched out we can figure out a better way to either expose the enums or only expose them to the casters.