[Numpy-discussion] draft enum NEP

Nathaniel Smith njs@pobox....
Fri Mar 9 14:00:48 CST 2012


On Fri, Mar 9, 2012 at 4:55 PM, Bryan Van de Ven <bryanv@continuum.io> 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


More information about the NumPy-Discussion mailing list