
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:
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~

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@stoneleaf.us> wrote:
-- --Guido van Rossum (python.org/~guido)

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@python.org> wrote:
-- [image: pattern-sig.png] Matt Gilson // SOFTWARE ENGINEER E: matt@getpattern.com // P: 603.892.7736 We’re looking for beta testers. Go here <https://www.getpattern.com/meetpattern> to sign up!

On 07/18/2016 09:53 AM, Matt Gilson wrote:
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.
Yeah, after I added the 'count_business_days' method I decided to break it apart as BusinessDays for the base behavior, and BankingHolidays for the members themselves; then it won't be US-centric. I just haven't gotten that far. -- ~Ethan~

On 19 July 2016 at 01:41, Guido van Rossum <guido@python.org> wrote:
I haven't used enum much outside the standard library, but my C/C++ background would push me towards CAP_WORDS since they're constants. That also has the virtue of making the standard library uses no longer a special case - they're just CAP_WORDS-because-they're-constants, rather than CAP_WORDS-because-they're-defined-by-a-third-party-C-API Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Jul 18, 2016, at 08:17 AM, Ethan Furman wrote:
Since in my code at least, I always include the enum class name at the call site, underscore_words for enum members is just fine. class Action(Enum): hold = 0 reject = 1 discard = 2 accept = 3 defer = 4 ... if action in (Action.defer, Action.hold): # ... elif action is Action.discard: # ... elif action is Action.reject: # ... elif action is Action.accept: # ... and so on. Make the code less shifty :). Cheers, -Barry

On 18.07.2016 20:35, Barry Warsaw wrote:
and so on. Make the code less shifty :).
That's what I thought as well and good reference to repeating the namespace of the constants. +1 ALL_CAPS feels very inconvenient to me as it reminds me of 1) ancient history (DOS, C, etc.) and 2) A SHOUTING CONVERSATION WHICH GIVES TOO MUCH WEIGHT TO UNIMPORTANT THINGS!!!!! CAN YOU HERE MEEE?? ;-) Sven

Maybe a bit OT, but there are also holiday singletons defined in https://github.com/pydata/pandas/blob/master/pandas/tseries/holiday.py class USFederalHolidayCalendar(AbstractHolidayCalendar): """ US Federal Government Holiday Calendar based on rules specified by: https://www.opm.gov/policy-data-oversight/ snow-dismissal-procedures/federal-holidays/ """ class Holiday(object): """ Class that defines a holiday with start/end dates and rules for observance. """ def __init__(self, name, year=None, month=None, day=None, offset=None, observance=None, start_date=None, end_date=None, days_of_week=None): On Jul 18, 2016 11:18 AM, "Ethan Furman" <ethan@stoneleaf.us> wrote:

On Mon, Jul 18, 2016 at 10:17 AM Ethan Furman <ethan@stoneleaf.us> wrote:
Even if there's a better design as judged in isolation, it still might be best to stay consistent with socket module. To paraphrase "Jakob's Law": programmers spend most of their time using *other* libraries (such as socket, logging, etc.). So it's generally a good idea not to invent new interfaces.
participants (8)
-
Barry Warsaw
-
Ethan Furman
-
Guido van Rossum
-
Matt Gilson
-
Michael Selik
-
Nick Coghlan
-
Sven R. Kunze
-
Wes Turner