[Numpy-discussion] Parameterised dtypes

[Richard Hattersley]

Hi Nathaniel,

Thanks for the useful feedback - it'll definitely save me some time
chasing around the code base.

> dtype callbacks and ufuncs don't in general get access to the
> dtype object, so they can't access whatever parameters exist

Indeed - it is a little awkward. But I'm hoping I can use the `data`
argument to supply this.

> You don't even need 'metadata' or 'c_metadata' -- this is Python, we
> already have a totally standard way to add new fields, just subclass
> the dumb thing.

That would be nice ... but Py_TPFLAGS_BASETYPE is not set for
PyArrayDescr_Type so that class is "final".

> 1) No, you can't hook into the dtype string parser. Though, are you
> sure you really want to? Surely it's nicer to use Python syntax
> instead of inventing a new syntax and then having to write a parser
> for it from scratch?

Thank you - that's good to know. As you say, I'd *far* rather avoid
parsing, but I'd like my dtype to be a "good citizen" so I was asking
out of completeness. (Off at a tangent: The blaze project is a good
example of what happens if you do add more parsing. In my opinion it's
not the way to go.)

> 2) I have some vague plans worked out to fix all this so dtypes are
> just ordinary python objects, but haven't written it down yet due to a
> combination of lack of time to do so, and lack of anyone with time to
> actually implement the plan even if it were written down. I mention
> this just in case someone wants to volunteer, which would move it up
> my stack.

Would you have the time to sketch out the intended benefits?

Richard