NEP 41: Is there still need to discuss DTypes vs. Scalars (or DType classes)?
the week has passed, and it has been discussed quite a bit longer, so I
assume that NEP 41 can effectively be accepted.
Even then, I will bring up one point again. I hope that if there is
still need for discussion, it will hopefully happen in a timely manner,
so that, I can go ahead with some changes proposed in NEP 41, and in
the event of more concrete doubts/issues there will only be few changes
that need to be undone. I would hate to revert large amount of work,
simply because an important point/issue is raised in two months instead
of two weeks.
This whole thing is fairly complex, so please do not hesitate to ask
I am also very happy to do a video conference with anyone interested at
any time, or chat in private on Slack.
So just in case: I will be available around 11:00 PDT (18 UTC) this
Thursday on the NumPy Community Call zoom link .
As far as I am aware, there was only one (maybe 2, see point 2. below
which may be independent) discussion points.
In my proposal the DType class (i.e. `type(np.dtype("float64")`), is
the core concept and different for every scalar type. It holds all the
information on how to deal with array elements.
This is some duplication of scalar types and it means that there would
be (usually) exactly one DType for each (NumPy) scalar, possibly
That does create a certain duality. For each scalar type/class, there
is a corresponding DType class. And in theory the scalar does not even
need to know that NumPy has a DType for it.
From a typing theoretical point of view this is also a bit strange. The
type of each array element is identical to the scalar type! But
although there is only one type, there are two distinct classes: one
for the scalar value, and one to explain them to NumPy and store them
in an array.
I lean in that direction because:
1. I wanted to modify scalars as little as possible, I am not sure we
will enable this initially, but this is so that:
* In principle you can create a DType for every Python type without
touching the original Python scalar.
* The scalar need not know about NumPy or DTypes thus creating no
new dependency. (you can use the scalar without installing NumPy)
2. I somewhat like that DType classes have methods that get a "self"
instance argument and are provided with the data by the array.
* This makes functions `dtype.__get_array_item__(item_memory)` is
implemented like a method:
def __get_array_item__(self, item_memory):
* There is an alternative approach to this, that I did not think
about much, though.
`item_memory` really is much like a scalar instance (it holds the
actual value), so you can argue that `item_memory` is `self` here,
and the dtype instance is the type of `item_memory` (the self).
E.g. making `__get_array_item__` live on the dtype (not on
the class). The dtype thus is the type/class of the array
This is beautiful, but, in generally you still need to pass
the dtype instance itself. For example strings cannot interpret
without knowing their length. In other words, the scalar `self` is
actually the tuple `(item_memory, dtype)`, which I think is why
at least I do not have a clear grasp here. 
3. There may be `dtypes` without specific scalar types. I am not sure
this is actually a tidy theoretical concept, but an example is
the current Pandas Categorical.
The type of the scalars within a categorical array are arbitrary.
I am not actually sure that is theoretically tidy. E.g. Python
uses `enum.Enum`, a class factory, for a similar purpose, and
you have to use the `.value` attribute. But, desirable or not,
it would seem less straight forward to potentially allow if we
design this around the scalar type.
The main downside to using DTypes as proposed in NEP 41 in my opinion
is what I mentioned first:
We must have a DType class for every scalar class, even though at least
most scalars (i.e. all NumPy scalars, except the `object` dtype) can
easily be expanded into including all necessary information, maybe
they already include almost all of it.
In the NEP 41 framework the scalar could be build from the DType in
practice. Which may seem a bit strange. In general Scalar<->DType will
form a Unit of a sort. And this means that somewhere we have to map
scalars to DTypes.
So, in many ways, I actually do find the scalar version tidier myself.
But, I also find the "there is a DType class for every scalar
type/class" a straight forward user story even if there will be subtle
difference between DType and scalar class/type.
The point 2. may be independent of the whole scalar story, I am
conflating it here, because to me it applies more naturally in that
Re: NEP 41: Is there still need to discuss DTypes vs. Scalars (or DType classes)?
On 20/4/20 11:37 pm, Sebastian Berg wrote:
> Hi all,
> In my proposal the DType class (i.e. `type(np.dtype("float64")`), is
> the core concept and different for every scalar type. It holds all the
> information on how to deal with array elements.
> This is some duplication of scalar types and it means that there would
> be (usually) exactly one DType for each (NumPy) scalar, possibly
> exposed using:
> e.g. np.dtype[np.float64]
> That does create a certain duality. For each scalar type/class, there
> is a corresponding DType class. And in theory the scalar does not even
> need to know that NumPy has a DType for it.
I think this is the correct choice, As we have only a little time before
the 1.19 release, the refactoring will at the earliest reach users for
1.20. This gives us time to see how the whole refactoring works out, so
the choice can be reevaluated in the future. Without diving into detail,
this is the approach taken in the current version of the NEP, correct?
If so, I suggest we accept the NEP in its current form and publish it
one week from now.