hierarchy spelled wrong (here and below), also abstrace->abstract

fixed

@mhvk noted: Still feel this would logically be on dtype.type.format; maybe that can be the default in the upper class?

Or, perhaps better, just omit it altogether and focus on a method on a dtype that currently exists, overriding that in Color.

formatting exists on dtypes, it is based on a switch statement to get the proper formatting function in arrayprint. I am proposing to make that a method-based lookup on the dtype.

You mean the format function including the part where it determines, e.g., for integer the maximum size the string will be? I guess that is indeed logical to have on the dtype. Still, for the purpose of the NEP, it seems too complicated; if the point is to be able to override a dtype, I feel it would be better to have an example that is closer to what a dtype normally does, like interpreting a bit of memory.

@mhvk noted: Instead of formatting, I'd pick something that actually exists, perhaps the interpretation of the memory (either setting or getting).

The purpose of a categorical dtype, as far as I can tell, is to give textual meaning to the values in the ndarray. The only place that has meaning is when printing them.

Presumably, should be able to set that type with a string as well? Indeed, even accessing it should give, I would think, an ColorType scalar that is just an int with a different __str__ (heck, scalars come back to haunt us immediately!).

Overriding any of the PyArray_Descr functions or ufuncs requires C code. I was looking for an easy way to demonstrate a subclass, but it seems I only confused reviewers.

There seems to be no benefit to having GenericDtype any more. I thought the argument before that you don't necessarily want to override what int means, but want to be sure that itemsize exists, was logical, so I would move some of the __new__ above here (or stick with the metaclass, it really wasn't bad and could be used to auto-fill methods based on itemsize, etc.)

This __repr__ could move to GenericDtype, as it would be the same for float, string (and that gives it some purpose!)

Looking at this again, it seems strange that if arr.dtype is meant to be an instance, we are still creating a class here, with actual instantiation of the singleton doing nothing. It does seem one might then just as well just the class as the dtype and keep instantiation in reserve for something more interesting...

Or, more in the spirit of the PR (though with the metaclass, as the check for itemsize needs to come after initialization), could this be something like:

class UIntDtype(IntDtype):
    kind = 'u'
    def __init__(cls, itemsize):
        self.itemsize = itemsize
        self.minimum = 0
        self.maximum = (1 << itemsize) - 1

uint8dtype = UIntDtype(itemsize=8)

though with the metaclass, as the check for itemsize needs to come after initialization

Dtypes will be immutable, so I'd expect this to go through __new__

Note with the issubclass(np.dtype, type) approach from the outdate NEP, this last line could look like:

class uint8dtype(metaclass=UIntDtype, itemsize=8):
    pass

Thinking more, the metaclass does in fact seem the best idea, but it should check for the presence of itemsize on any instances not on the class, i.e., it should let type do its work, and then check that itemsize exists. This, of course, is just what ABCmeta does...