Smaller issues to keep in mind

[seberg]

Just a list of smaller issues so that we do not forget it (just in case):

• UFuncImpl/CastingImpl and DTypes will effectively have circular references. Many DTypes do not need to be heap types (reference counted), but some do have to be. We may need to implement some circular reference counting (and that may have some speed implications?!). This should not be a big issue, but if we have an idea of how to avoid it, I would be all ears

• UFunc type resolution will be fairly slow, thus we need the cache/dictionary of all lookups. This should for all practical purposes not really matter since the objects stored are small and should not be hundrets of thousands. However, in principle for ufuncs with many inputs/dtypes this could hold on to a lot of objects. We could opt to replace the dictionary cache with a limited size/faster LRU-like cache, or otherwise limit the size of the cache.

• Keep an eye on pandas NA implementations and implementation with respect to dtype being attached to NA (to me that seems the obvious solution, with a generic NA scalar also existing). We should be sharing this infrastructure with pandas.

• (from an old note on AbstractDTypes) Putting the common type promotion into the dtypes, means that the common type
  operation is not capable of being modified by a third party.
  This may or may not be good. For example a if I implement a unit dtype which
  knows about rationals (RationalUnit), then the common type promotion of:
  rational, Unit -> RationalUnit is well defined. However, there would be no
  way to discover it.
  One way around this could be to handle the common type operation using a ufunc like
  API and handle it with a registration based approach..