[Python-ideas] proper naming of Enum members

Matt Gilson matt at getpattern.com
Mon Jul 18 12:53:19 EDT 2016


I also generally think of Enum as a collection of constants so I favor
CAP_WORDS for enum members.  I will admit that my answer is biased in that
I don't typically create Enums that have a whole bunch of methods as you've
done in your example.  For your example code, I might separate it out into
two classes (something representing a Date and an enum representing a
Holidays).  The former class could use the latter to compute things like
"Next business day", etc.

On Mon, Jul 18, 2016 at 8:41 AM, Guido van Rossum <guido at python.org> wrote:

> Honestly my own preference would be to use UPPER_CASE, emphasizing the
> const-ness. CapWords is really only used for classes, which are
> entirely different beasts. And lower_case is for methods and
> variables. I think it's useful to emphasize that an enum is neither.
>
> On Mon, Jul 18, 2016 at 8:17 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> > There are currently a few locations in the stdlib, such as http and
> socket,
> > that are now using
> > Enums to replace constants; those names are all upper-case -- those
> aren't
> > the names I am
> > speaking of.
> >
> > The names I am speaking of are those in brand-new enumerations where we
> have
> > full control.
> >
> > As an example:
> >
> > class FederalHoliday(AutoNumberEnum):
> >     NewYear = "First day of the year.", 'absolute', JANUARY, 1
> >     MartinLutherKingJr = "Birth of Civil Rights leader.", 'relative',
> > JANUARY, MONDAY, 3
> >     President = "Birth of George Washington", 'relative', FEBRUARY,
> MONDAY,
> > 3
> >     Memorial = "Memory of fallen soldiers", 'relative', MAY, MONDAY, 5
> >     Independence = "Declaration of Independence", 'absolute', JULY, 4
> >     Labor = "American Labor Movement", 'relative', SEPTEMBER, MONDAY, 1
> >     Columbus = "Americas discovered", 'relative', OCTOBER, MONDAY, 2
> >     Veterans = "Recognition of Armed Forces service", 'relative',
> NOVEMBER,
> > 11, 1
> >     Thanksgiving = "Day of Thanks", 'relative', NOVEMBER, THURSDAY, 4
> >     Christmas = "Birth of Jesus Christ", 'absolute', DECEMBER, 25
> >
> >     def __init__(self, doc, type, month, day, occurance=None):
> >         self.__doc__ = doc
> >         self.type = type
> >         self.month = month
> >         self.day = day
> >         self.occurance = occurance
> >
> >     def date(self, year):
> >         """
> >         returns the observed date of the holiday for `year`
> >         """"
> >         ...
> >
> >     @classmethod
> >     def next_business_day(cls, date, days=1):
> >         """
> >         Return the next `days` business day from date.
> >         """
> >         ...
> >     @classmethod
> >     def count_business_days(cls, date1, date2):
> >         """
> >         Return the number of business days between 'date1' and 'date2'.
> >         """
> >         ...
> >     @classmethod
> >     def year(cls, year):
> >         """
> >         Return a list of the actual FederalHoliday dates for `year`.
> >         """
> >         ...
> > Take the name "NewYear":  if it had been a global constant I would have
> > named it "NEWYEAR"; if
> > it had been a normal class attribute I would have named it "new_year";
> > however, being an Enum
> > member, it is neither of those things.
> >
> > <context switch>
> > I've written some custom data types as part of my dbf package, and a few
> of
> > them have instances
> > that are singletons that are created in the global (okay, module)
> namespace,
> > and for them I
> > followed Python's lead in naming singletons:  Python has used Title Case
> in
> > such things as None,
> > True, and False, so I followed suit and named mine -- Null, NullDate,
> > NullTime, NullDateTime, etc.
> > </context switch>
> >
> > Given my past history with using and creating singleton objects, I
> followed
> > suit when creating
> > my own Enum classes.
> >
> > I was recently queried about my apparent break with PEP 8 for naming Enum
> > members, to which I
> > replied:
> >
> >> Considering the strange beast that an Enum is, there is not much
> precedent
> >> for it anywhere.
> >>
> >> Consider:
> >>
> >> - Enum is a class
> >> -   but it is a container
> >> -   and can be iterated over
> >> -   and it has a length (which can be zero)
> >> -   but it's always True in a boolean sense
> >>
> >> - Enum members are instances of the Enum class
> >> -   but are pre-created
> >> -   and new ones cannot be created
> >> -   but are available as attributes on the class
> >>
> >> Given all that I have been using Title case (or CamelCase) to name the
> >> members as it helps
> >> distinguish an Enum member from an ordinary attribute (which Enum
> classes
> >> can also have).
> >
> >
> > I forgot to include in that reply that I think CamelCase also helps to
> > emphasize the special
> > singleton nature of Enum members.
> >
> > My question for the community:  Your thoughts/opinions of my reasoning,
> and
> > if you don't agree
> > then which casing choice would you recommend and use, and why?
> (Reminder:
> > this question does
> > not include Enums whose names are replacements for existing constants
> and so
> > the names cannot
> > be changed.)
> >
> > --
> > ~Ethan~
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

[image: pattern-sig.png]

Matt Gilson // SOFTWARE ENGINEER

E: matt at getpattern.com // P: 603.892.7736

We’re looking for beta testers.  Go here
<https://www.getpattern.com/meetpattern> to sign up!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160718/12febae4/attachment.html>


More information about the Python-ideas mailing list