[Python-ideas] constant/enum type in stdlib

Eli Bendersky eliben at gmail.com
Mon Feb 4 05:51:35 CET 2013


On Sun, Feb 3, 2013 at 3:53 PM, João Bernardo <jbvsmo at gmail.com> wrote:

> Hi, about this enum/const thing, The use case I like more is a class where
> you know all the
> instances and not just a sequence of names.
> Particularly It would be nice to have custom attributes and methods
> besides the value and the name.
>
> I have my own implementation with a basic api somewhat borrowed from
> flufl.enum (plus a lot of other stuff),
> but with this kind of support: https://github.com/jbvsmo/makeobj
>
> I couldn't find the best way to express enums with the current python
> syntax, so I also wrote a simple
> regex-parsed language to fit objects with an arbitrary level of
> complexity. I think, enumeration per se
> is not much more useful than just a bunch of integers... Having this kind
> of control IMO is.
>
> Although Java is not a good example of anything, they have a similar
> feature. What do you people think?
>
>

Personally, I disagree with the "more features is better" approach.
Features have a cost - they complicate the implementation which makes it
fragile, harder to maintain and harder to understand. Even more
importantly, they make *user* code harder to understand.

Therefore it's IMHO best to decide on a basic functionality that brings
most of the benefits, and then think about how to make the implementation
*simpler*. All I really want from an enum is what I have in C and lack in
Python - a nice, minimally type-safe way to name special constants. Having
this in hand, I want the simplest and cleanest syntax possible, not more
features.

Tim's implementation strikes a good balance - the syntax is as minimal as
can be in a library implementation, and it provides all the basic features
well. It adds some more, possibly at the cost of complexity, which may or
may not be good. This is why I think that a PEP weighing features
for/against inclusion is a logical next step.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130203/d5eda837/attachment.html>


More information about the Python-ideas mailing list