[Python-ideas] PEP for enum library type?

[Nick Coghlan]

On Thu, Feb 14, 2013 at 5:35 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Hint: nobody would find the convenience function API as obvious as the
> subclassing API.

# Status quo
one, two, three, four = range(4)

# flufl.enum.make -> types.new_enum
# Factory function for classes
# For when you don't care about the specific values
# Close parallel to collections.namedtuple
OneToFour = types.new_enum("OneToFour", "one two three four")

# flufl.enum.Enum -> types.Enum
# For when you do care about (some) specific values
class OneToFourAndTen(OneToFour):
    ten = 10

collections.namedtuple is the normative example here, and while the
repetition of the class name is still annoying, that's a minor
irritation compared to completely violating everyone's expectations of
normal class behaviour.

>> Magic namespaces and metaclasses sure don't meet *my* definition of
>> obvious.
>
> Perhaps, but Python is not a supermarket where you choose your own brand
> of obvious as you like. It's a programming language striving to
> provide a rather consistent experience. People with bizarre tastes can
> always publish their packages on PyPI.

In which case, they should stop discussing them on python-ideas.
flufl.enum is a perfectly fine example of normal Pythonic class
design, with similar examples already in the standard library. The
approaches being thrown around on this list lately are very cool from
a technical point of view, and impressive illustrations of what
Python's metaclass machinery can do for you, but they're also
completely unintuitive black magic (including "x = ..." having any
result other than "x is Ellipsis").

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia