On Fri, Mar 9, 2012 at 4:55 PM, Bryan Van de Ven <[email protected]> wrote: > Hi all, > > I have started working on a NEP for adding an enumerated type to NumPy. > It is on my GitHub: > > https://github.com/bryevdv/numpy/blob/enum/doc/neps/enum.rst > > It is still very rough, and incomplete in places. But I would like to > get feedback sooner rather than later in order to refine it. In > particular there are a few questions inline in the document that I would > like input on. Any comments, suggestions, questions, concerns, etc. are > very welcome.
Hi Bryan, That's excellent, an enumerated type would be very useful. From a quick read, though, what I'd really like to see is some discussion of the goals here -- like some example situations where you see these being used, and the problems they're intended to solve? Because for example, C "enums" are designed to solve a completely different problem than something like an R "factor", and off the top of my head I don't know how well either maps onto hdf5 enumerated types. Another example is that I can't tell from the document what the motivation for having both "open" and "closed" enums is? (Also, general question: is there some technical advantage to being able to represent more complicated dtypes as strings, that justifies making up these mini-languages like "enum:uint16[A, B, C, D, E:128]"? It can't be necessary for pickling or anything, right, since AFAICT there's already no string representation for structured dtypes? It just seems like it'd be simpler and more elegant to use some Python syntax like 'dtype(Enum(["a", "b", "c"], storage=np.uint16))' instead of writing a tiny one-off parser and wedging what's really a data structure into a string, but I may be missing something.) -- Nathaniel _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
