Re: Baroque [was Re: Should nested classes in an Enum be Enum members?]
On 06/29/2018 05:51 PM, Steven D'Aprano wrote: So not especially complimentary (sorry Ethan, but that was my first impression) but not *necessarily* a bad thing either. No worries! :) The Jargon File adjective that comes closest is probably gnarly: Wow, I haven't heard that word in a long time. Just for the record: https://en.wiktionary.org/wiki/baraque baraque f (plural baraques) shack, hut stall, stand (colloquial) pad, crib (house) (informal) a musclehead So, you can see why I was confused! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Fri, 29 Jun 2018 10:36:45 -0700, Ethan Furman wrote: >> What makes them enums? Under what circumstances would you be comparing >> something to MartinLutherKingJr (Day) without caring about a *specific* >> Martin Luther King Jr Day? > > Enums are also useful when the underlying value is relevant; the usual > example is communicating with other languages' APIs. While those > relevant values may have no intrinsic value, why is it a problem if they > do? But surely the underlying value of holidays *is* something we care about: the date it falls. We don't just care about "Martin Luther King Jr Day" as an abstraction, we do care about the specific day it falls, we care about its relationship to other days: - what's the last business day before MKKJ Day? - what's the next business day after it? - what's the date of it this year? - will it ever fall on my birthday? etc. I think that once we start adding methods to enums, we're starting to move into a gray area where they aren't *really* arbitrary enumerated values any longer. (Maybe.) If your methods use "self", then they implicitly care about the value of the enum. I think it's a matter of degree. Past a certain level of complexity, the object isn't an enum any more. I don't have a problem with the "planets" example for enums. (Maybe I should?) But your example seems to have crossed that line for me. At one extreme, we have pure symbols, or atoms, where the values don't support any significant operations apart from such trivial operations such as a human-readable string representation. Examples in Python include None, Ellipsis and NotImplemented. https://en.wikipedia.org/wiki/Symbol_%28programming%29 On the other extreme, we have rich, complex data types which support many non-trivial operations, like dicts, tuples, floats and web server objects. These typically (but not always) support a notion of equality beyond just identity. I think enums naturally belong very close to the Symbol end of the continuum, and I can't help but feel your Federal Holiday example is sufficiently far from that end that using Enum feels uncomfortable to me. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Baroque [was Re: Should nested classes in an Enum be Enum members?]
On Sat, Jun 30, 2018 at 10:51 AM, Steven D'Aprano wrote: > ["Baroque"] should not mean "weird or bizarre", although I've seen a couple of > lesser-quality dictionaries give that as a meaning. Which is itself weird > and bizarre :-) > I guess those dictionaries are baroque. Or maybe just broke. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Baroque [was Re: Should nested classes in an Enum be Enum members?]
On Sat, 30 Jun 2018 09:02:37 +1000, Cameron Simpson wrote: > On 29Jun2018 10:36, Ethan Furman wrote: >>On 06/28/2018 10:52 PM, Steven D'Aprano wrote: >>>It isn't clear to me why FederalHoliday is an Enum, especially as the >>>API seems extremely baraque. >> >>Huh. I had to look that word up, and I still don't know what you meant >>exactly, although I suspect it wasn't complimentary. ;-) > > It tends to mean "weird", but perhaps a more nuanced phrasing might be > unusual and strange, and usually connotes some degree of over > complication. It might have helped if I spelled it correctly, sorry. It should not mean "weird or bizarre", although I've seen a couple of lesser-quality dictionaries give that as a meaning. Which is itself weird and bizarre :-) The more established meanings are: - literally, it refers to the Baroque style of art, music and architecture popular in Europe between (approximately) 1600 and 1750; - figuratively, it means to be highly ornate and elaborate, with strong connotations of being *excessively* complicated to the point of being convoluted. https://en.oxforddictionaries.com/definition/baroque http://www.dictionary.com/browse/baroque So not especially complimentary (sorry Ethan, but that was my first impression) but not *necessarily* a bad thing either. The Jargon File adjective that comes closest is probably gnarly: http://www.catb.org/jargon/html/G/gnarly.html but that's probably stronger with even worse connotations than baroque. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
Cameron Simpson wrote: It tends to mean "weird", but perhaps a more nuanced phrasing might be unusual and strange, and usually connotes some degree of over complication. When used in a derogatory way it means "excessively elaborate". The Baroque period was characterised by extremely ornate architecture, music, etc. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
Ethan Furman wrote: They are the list of dates in which US banks are closed for electronic business (funds transfers and things). That sems like something that would be better specified in a configuration file than hard-wired into the code, in case the rules change. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 06/29/18 16:02, Cameron Simpson wrote: On 29Jun2018 10:36, Ethan Furman wrote: On 06/28/2018 10:52 PM, Steven D'Aprano wrote: On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote: Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. Note that date(), next_business_day, and year() are all callables. The AutoEnum parent assigns values from 1 to n for each member. It's at Stackoverflow [1] if you'd like up- or down-vote it. ;) It isn't clear to me why FederalHoliday is an Enum, especially as the API seems extremely baraque. Huh. I had to look that word up, and I still don't know what you meant exactly, although I suspect it wasn't complimentary. ;-) It tends to mean "weird", but perhaps a more nuanced phrasing might be unusual and strange, and usually connotes some degree of over complication. Cheers, Cameron Simpson It's actually "baroque", not "baraque", and Cameron has the right idea - lavish, extravagant, overly complicated. -Jim -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 29Jun2018 10:36, Ethan Furman wrote: On 06/28/2018 10:52 PM, Steven D'Aprano wrote: On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote: Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. Note that date(), next_business_day, and year() are all callables. The AutoEnum parent assigns values from 1 to n for each member. It's at Stackoverflow [1] if you'd like up- or down-vote it. ;) It isn't clear to me why FederalHoliday is an Enum, especially as the API seems extremely baraque. Huh. I had to look that word up, and I still don't know what you meant exactly, although I suspect it wasn't complimentary. ;-) It tends to mean "weird", but perhaps a more nuanced phrasing might be unusual and strange, and usually connotes some degree of over complication. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 06/28/2018 10:52 PM, Steven D'Aprano wrote: On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote: Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. Note that date(), next_business_day, and year() are all callables. The AutoEnum parent assigns values from 1 to n for each member. It's at Stackoverflow [1] if you'd like up- or down-vote it. ;) It isn't clear to me why FederalHoliday is an Enum, especially as the API seems extremely baraque. Huh. I had to look that word up, and I still don't know what you meant exactly, although I suspect it wasn't complimentary. ;-) class FederalHoliday(AutoEnum): NewYear = "First day of the year.", 'absolute', Month.JANUARY, 1 MartinLutherKingJr = "Birth of Civil Rights leader.", \ 'relative', Month.JANUARY, Weekday.MONDAY, 3 ... I think I get the idea... the first field is a description, the second tells us what month the holiday is in (hope you don't have to deal with movable holidays which can change months...). I'm not quite sure what the "absolute/relative" flags are (or why they are strings instead of enums). Possibly they determine whether the next field is treated as an ordinal (first, second, third...) or numerical (1, 2, 3...) value. - description - type (absolute or relative) - month - if absolute: - date - else: - week day - which one But what isn't clear to me is why these holidays are *enums*. They're obviously date instances, with a rich API (at least three methods) and an extremely complex constructor (one with variable numbers of arguments). They are the list of dates in which US banks are closed for electronic business (funds transfers and things). What makes them enums? Under what circumstances would you be comparing something to MartinLutherKingJr (Day) without caring about a *specific* Martin Luther King Jr Day? Enums are also useful when the underlying value is relevant; the usual example is communicating with other languages' APIs. While those relevant values may have no intrinsic value, why is it a problem if they do? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 29/06/2018 09:01, Ian Kelly wrote: On Thu, Jun 28, 2018 at 10:06 PM Ben Finney wrote: @total_ordering class ChessPiece(Enum): PAWN = 1, 'P' KNIGHT = 2, 'N' BISHOP = 3, 'B' ROOK = 4, 'R' # ... @property def label(self): return self.value[1] def __lt__(self, other): assert isinstance(other, ChessPiece) return self.value < other.value This enum type defines its own ordering based on the relative values of the chess pieces. class ChessPiece(Enum): PAWN = 'P', pawn_moves, pawn_attacks KNIGHT = 'N', knight_moves, knight_attacks BISHOP = 'B', bishop_moves, bishop_attacks ROOK = 'R', rook_moves, rook_attacks # ... def moves(self, board, from_square): return self.value[1](board, from_square) def attacks(self, board, from_square): return self.value[2](board, from_square) Now, elsewhere we can easily do something like: all_moves = [] for square in board: piece = board[square] if piece: all_moves.extend(piece.moves(board, square)) Et voila. ChessPiece is still an enum as it should be, and it also has a useful API on top of that. I get the feeling is that the enum (PAWN, BISHOP etc) is a property of a piece, rather than being the cornerstone of everything you might think of doing with a chess-piece. That thinking keeps the that property as a simple type, a simple enum of six distinct values with nothing else piled on top to complicate matters. And it means the same enum can be used in other contexts associated with chess where that other data may be irrelevant. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, Jun 28, 2018 at 10:06 PM Ben Finney wrote: > > Ethan Furman writes: > > > On 06/28/2018 05:58 PM, Ben Finney wrote: > > > > > So I remain dumbfounded as to why anyone would want a class to *both* be > > > an enumerated type, *and* have callable attributes in its API. > > > > Perhaps I am using Enum incorrectly, but here is my FederalHoliday > > Enum. […] > > Thanks for the example. Yes, my personal impression is that class > is not a good use of enum.Enum (nor enum.AutoEnum). > > To inherit from enum.Enum (or enum.AutoEnum) signals, to my mind, that > the class is not really intended as a typical Python class, but instead > is intended to be that special beast known as an “enumerated type” which > has little behaviour other than being a namespace for constant values. That sounds like a C attitude talking. Python enums are heavily inspired by Java enums, which also permit enum members to have attributes and methods. In fact, that planets example that Steven mentioned is ripped straight out of the Java documentation. You may find it weird, but I actually find it really, really useful to be able to attach methods to enums. For example: class Color(Enum): RED = 'red' GREEN = 'green' BLUE = 'blue' def __str__(self): return 'the color %s' % self.value How else is one to override the str() of an enum? Another example: @total_ordering class ChessPiece(Enum): PAWN = 1, 'P' KNIGHT = 2, 'N' BISHOP = 3, 'B' ROOK = 4, 'R' # ... @property def label(self): return self.value[1] def __lt__(self, other): assert isinstance(other, ChessPiece) return self.value < other.value This enum type defines its own ordering based on the relative values of the chess pieces. To be fair, Java does this a bit better than Python does. For example, Java allows enum methods to be overridden by individual enum members. This makes it easy to, e.g., implement a Strategy pattern where the Strategy of choice depends upon an enum value. If you want to do that in Python, you're pretty much stuck with passing either lambdas or functions defined elsewhere as part of the enum member's value. But we can do it, which leads us to our next example: def pawn_moves(board, from_square): "Generate all pawn moves possible from the given square." # ... def knight_moves(board, from_square): "Generate all knight moves possible from the given square." # ... def pawn_attacks(board, from_square): "Generate all squares that would be attacked by a pawn a the given square." # ... # ... class ChessPiece(Enum): PAWN = 'P', pawn_moves, pawn_attacks KNIGHT = 'N', knight_moves, knight_attacks BISHOP = 'B', bishop_moves, bishop_attacks ROOK = 'R', rook_moves, rook_attacks # ... def moves(self, board, from_square): return self.value[1](board, from_square) def attacks(self, board, from_square): return self.value[2](board, from_square) Now, elsewhere we can easily do something like: all_moves = [] for square in board: piece = board[square] if piece: all_moves.extend(piece.moves(board, square)) Et voila. ChessPiece is still an enum as it should be, and it also has a useful API on top of that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, Jun 28, 2018 at 7:01 PM Ben Finney wrote: > > Ian Kelly writes: > > > On Thu, Jun 28, 2018 at 4:38 AM Ben Finney > > wrote: > > > > > > Ethan Furman writes: > > > > > > Specifically, I can't make sense of why someone would want to have a > > > class that is simultaneously behaving as an enumerated type, *and* > > > has an API of custom callable attributes. > > > > You don't see value in enum members having properties? > > Is a Python property a callable attribute? I was referring to properties generically in the OOP sense, not to Python properties specifically. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote: > On 06/28/2018 05:58 PM, Ben Finney wrote: > >> So I remain dumbfounded as to why anyone would want a class to *both* >> be an enumerated type, *and* have callable attributes in its API. > > Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. > Note that date(), next_business_day, and year() are all callables. The > AutoEnum parent assigns values from 1 to n for each member. It's at > Stackoverflow [1] if you'd like up- or down-vote it. ;) It isn't clear to me why FederalHoliday is an Enum, especially as the API seems extremely baraque. > class FederalHoliday(AutoEnum): > NewYear = "First day of the year.", 'absolute', Month.JANUARY, 1 > MartinLutherKingJr = "Birth of Civil Rights leader.", \ > 'relative', Month.JANUARY, Weekday.MONDAY, 3 ... I think I get the idea... the first field is a description, the second tells us what month the holiday is in (hope you don't have to deal with movable holidays which can change months...). I'm not quite sure what the "absolute/relative" flags are (or why they are strings instead of enums). Possibly they determine whether the next field is treated as an ordinal (first, second, third...) or numerical (1, 2, 3...) value. But what isn't clear to me is why these holidays are *enums*. They're obviously date instances, with a rich API (at least three methods) and an extremely complex constructor (one with variable numbers of arguments). What makes them enums? Under what circumstances would you be comparing something to MartinLutherKingJr (Day) without caring about a *specific* Martin Luther King Jr Day? -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
Ethan Furman writes: > On 06/28/2018 05:58 PM, Ben Finney wrote: > > > So I remain dumbfounded as to why anyone would want a class to *both* be > > an enumerated type, *and* have callable attributes in its API. > > Perhaps I am using Enum incorrectly, but here is my FederalHoliday > Enum. […] Thanks for the example. Yes, my personal impression is that class is not a good use of enum.Enum (nor enum.AutoEnum). To inherit from enum.Enum (or enum.AutoEnum) signals, to my mind, that the class is not really intended as a typical Python class, but instead is intended to be that special beast known as an “enumerated type” which has little behaviour other than being a namespace for constant values. Adding all that other stuff just makes it quite unclear what the class means any more. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but me and Pippi Longstocking — I mean, what would the | _o__) children look like?” —_Pinky and The Brain_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 06/28/2018 05:58 PM, Ben Finney wrote: So I remain dumbfounded as to why anyone would want a class to *both* be an enumerated type, *and* have callable attributes in its API. Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. Note that date(), next_business_day, and year() are all callables. The AutoEnum parent assigns values from 1 to n for each member. It's at Stackoverflow [1] if you'd like up- or down-vote it. ;) --- class FederalHoliday(AutoEnum): NewYear = "First day of the year.", 'absolute', Month.JANUARY, 1 MartinLutherKingJr = "Birth of Civil Rights leader.", 'relative', Month.JANUARY, Weekday.MONDAY, 3 President = "Birth of George Washington", 'relative', Month.FEBRUARY, Weekday.MONDAY, 3 Memorial = "Memory of fallen soldiers", 'relative', Month.MAY, Weekday.MONDAY, 5 Independence = "Declaration of Independence", 'absolute', Month.JULY, 4 Labor = "American Labor Movement", 'relative', Month.SEPTEMBER, Weekday.MONDAY, 1 Columbus = "Americas discovered", 'relative', Month.OCTOBER, Weekday.MONDAY, 2 Veterans = "Recognition of Armed Forces service", 'relative', Month.NOVEMBER, 11, 1 Thanksgiving = "Day of Thanks", 'relative', Month.NOVEMBER, Weekday.THURSDAY, 4 Christmas = "Birth of Jesus Christ", 'absolute', Month.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`" if self.type == 'absolute' or isinstance(self.day, int): holiday = Date(year, self.month, self.day) if Weekday(holiday.isoweekday()) is Weekday.SUNDAY: holiday = holiday.replace(delta_day=1) return holiday days_in_month = days_per_month(year) target_end = self.occurance * 7 + 1 if target_end > days_in_month[self.month]: target_end = days_in_month[self.month] target_start = target_end - 7 target_week = list(xrange(start=Date(year, self.month, target_start), step=one_day, count=7)) for holiday in target_week: if Weekday(holiday.isoweekday()) is self.day: return holiday @classmethod def next_business_day(cls, date, days=1): """ Return the next `days` business day from date. """ holidays = cls.year(date.year) years = set([date.year]) while days > 0: date = date.replace(delta_day=1) if date.year not in years: holidays.extend(cls.year(date.year)) years.add(date.year) if Weekday(date.isoweekday()) in (Weekday.SATURDAY, Weekday.SUNDAY) or date in holidays: continue days -= 1 return date @classmethod def year(cls, year): """ Return a list of the actual FederalHoliday dates for `year`. """ holidays = [] for fh in cls: holidays.append(fh.date(year)) return holidays -- ~Ethan~ [1] https://stackoverflow.com/a/22594360/208880 -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, 28 Jun 2018 20:34:58 +1000, Ben Finney wrote: > Ethan Furman writes: > >> Consider the following Enum definition: >> >> class Color(Enum): >> RED = 1 >> GREEN = 2 >> BLUE = 3 >> @property >> def lower(self): >> return self.name.lower() >> def spam(self): >> return "I like %s eggs and spam!" % self.lower >> class SomeClass: >> pass > > That dumbfounds my intuitions. > > Specifically, I can't make sense of why someone would want to have a > class that is simultaneously behaving as an enumerated type, *and* has > an API of custom callable attributes. The PEP gives an example of enumerated members that themselves have methods. https://www.python.org/dev/peps/pep-0435/ There was another example somewhere (I don't remember where) of an enumeration of the planets, where planets can have attributes and methods: Planet.MARS.mass Planet.JUPITER.moons() which is no more weird than this: class Planet(Enum): MARS = "the red planet" Planet.MARS.upper() -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, 28 Jun 2018 08:36:47 -0700, Ethan Furman wrote: >>> Answer: >>> >>> - RED, GREEN, and BLUE are members >>> - lower and spam() are not >>> - SomeClass /is/ a member (but not its instances) >> >> Is that by accident or by design? > > By design. It is entirely possible to want an enum of types (int, > float, str, etc.). Seems strange to me. Why enum of types but not an enum of functions or methods? Perhaps you could have had an explicit decorator? class Colours(Enum): RED = 1 class Spam(object): pass @Enum.member class Eggs(object): pass Colours.Eggs will be an enum member, Spam will not be. But I suppose backwards compatibility rules that out. >> class Colour(Enum): >> class PrimaryColour(Enum): >> RED = 1 >> GREEN = 2 >> BLUE = 3 >> OCTARINE = 8 >> class SecondaryColour(Enum): >> PUCE = 101 >> MAUVE = 102 >> BEIGE = 103 >> TEAL = 104 > > This really seems to be the sticking point -- what should an Enum of > Enums look like? For example, should the above do > >--> list(Colour) >[Colour.PrimaryColour <...>, Colour.SecondaryColour <...>] > > or something else? I would expect the inner classes to disappear: [Colour.RED, Colour.GREEN, ... Colour.PUCE, ... ] unless I explicitly inspect their types: type(Colour.RED) => returns Colour.PrimaryColour But maybe there's another way to get that same effect? # ??? class PrimaryColour(Enum): RED = 1 ... class SecondaryColour(Enum): ... Colour = PrimaryColour + SecondaryColour -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
Ian Kelly writes: > On Thu, Jun 28, 2018 at 4:38 AM Ben Finney wrote: > > > > Ethan Furman writes: > > > > Specifically, I can't make sense of why someone would want to have a > > class that is simultaneously behaving as an enumerated type, *and* > > has an API of custom callable attributes. > > You don't see value in enum members having properties? Is a Python property a callable attribute? >>> class Lorem: ... @property ... def spam(self): ... print(self) ... >>> foo = Lorem() >>> foo.spam() <__main__.Lorem object at 0x7ff5078bc710> Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not callable It seems that no, a property is not a callable attribute. So I remain dumbfounded as to why anyone would want a class to *both* be an enumerated type, *and* have callable attributes in its API. -- \ “It's dangerous to be right when the government is wrong.” | `\ —Francois Marie Arouet Voltaire | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Thu, Jun 28, 2018 at 4:38 AM Ben Finney wrote: > > Ethan Furman writes: > > > Consider the following Enum definition: > > > > class Color(Enum): > > RED = 1 > > GREEN = 2 > > BLUE = 3 > > @property > > def lower(self): > > return self.name.lower() > > def spam(self): > > return "I like %s eggs and spam!" % self.lower > > class SomeClass: > > pass > > That dumbfounds my intuitions. > > Specifically, I can't make sense of why someone would want to have a > class that is simultaneously behaving as an enumerated type, *and* has > an API of custom callable attributes. You don't see value in enum members having properties? -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 06/28/2018 01:11 AM, Steven D'Aprano wrote: On Wed, 27 Jun 2018 07:48:53 -0700, Ethan Furman wrote: [Note: there is a similar thread on Python-Ideas, if you would like to respond there.] Consider the following Enum definition: class Color(Enum): RED = 1 GREEN = 2 BLUE = 3 @property def lower(self): return self.name.lower() def spam(self): return "I like %s eggs and spam!" % self.lower class SomeClass: pass Which of the above Color attributes are enums, and which aren't? (In hindsight perhaps you should have called the class EnumType so that ambiguity would not exist. Then an enum would *always* refer to the members Color.RED etc, and never to Color itself.) The problem then is the ambiguity between EnumMeta and EnumType. :/ Answer: - RED, GREEN, and BLUE are members - lower and spam() are not - SomeClass /is/ a member (but not its instances) Is that by accident or by design? By design. It is entirely possible to want an enum of types (int, float, str, etc.). Question: Should `SomeClass` be an enum member? When would it be useful to have an embedded class in an Enum be an enum member? I honestly cannot think of any reason to nest a class inside of an Enum class. But if I did, I would probably want it to be just a regular class, and not an enum member. If I wanted to nest an Enum class inside an Enum class (but why???) I'd just inherit from Enum: class Colour(Enum): class PrimaryColour(Enum): RED = 1 GREEN = 2 BLUE = 3 OCTARINE = 8 class SecondaryColour(Enum): PUCE = 101 MAUVE = 102 BEIGE = 103 TEAL = 104 This really seems to be the sticking point -- what should an Enum of Enums look like? For example, should the above do --> list(Colour) [Colour.PrimaryColour <...>, Colour.SecondaryColour <...>] or something else? The only example I have seen so far of nested classes in an Enum is when folks want to make an Enum of Enums, and the nested Enum should not itself be an enum member. Since the counter-example already works I haven't seen any requests for it. ;) So I'm asking the community: What real-world examples can you offer for either behavior? Cases where nested classes should be enum members, and cases where nested classes should not be members. Is this a trick question? Heh. Not at all. It is entirely possible to have a real use-case which we cannot model the way we want in code. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
Ethan Furman writes: > Consider the following Enum definition: > > class Color(Enum): > RED = 1 > GREEN = 2 > BLUE = 3 > @property > def lower(self): > return self.name.lower() > def spam(self): > return "I like %s eggs and spam!" % self.lower > class SomeClass: > pass That dumbfounds my intuitions. Specifically, I can't make sense of why someone would want to have a class that is simultaneously behaving as an enumerated type, *and* has an API of custom callable attributes. > Question: > > Should `SomeClass` be an enum member? When would it be useful to > have an embedded class in an Enum be an enum member? I can't think of a satisfactory answer to the question “Why is SomeClass defined inside that enumerated type at all?” > So I'm asking the community: What real-world examples can you offer > for either behavior? That set is empty. I'd be going straight to the author of that code; or, if that weren't an option, re-factoring that code at the next opportunity. -- \ “Our urge to trust our senses overpowers what our measuring | `\ devices tell us about the actual nature of reality.” —Ann | _o__) Druyan, _Cosmos_, 2014 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On Wed, 27 Jun 2018 07:48:53 -0700, Ethan Furman wrote: > [Note: there is a similar thread on Python-Ideas, if you would like to > respond there.] > > Consider the following Enum definition: > >class Color(Enum): >RED = 1 >GREEN = 2 >BLUE = 3 >@property >def lower(self): >return self.name.lower() >def spam(self): >return "I like %s eggs and spam!" % self.lower >class SomeClass: >pass > > Which of the above Color attributes are enums, and which aren't? The question is ambiguous in the case of SomeClass. It could mean that: - SomeClass is the same kind of thing as Color (an Enum subclass); - SomeClass is the same kind of thing as Color.RED (an enum member); - or neither of the above. (In hindsight perhaps you should have called the class EnumType so that ambiguity would not exist. Then an enum would *always* refer to the members Color.RED etc, and never to Color itself.) Without trying it, or reading ahead, I would not want to guess which was the case. [ s p o i l e r s p a c e ] > Answer: > >- RED, GREEN, and BLUE are members >- lower and spam() are not >- SomeClass /is/ a member (but not its instances) Is that by accident or by design? > Question: > >Should `SomeClass` be an enum member? When would it be useful to >have an embedded class in an Enum be an enum member? I honestly cannot think of any reason to nest a class inside of an Enum class. But if I did, I would probably want it to be just a regular class, and not an enum member. If I wanted to nest an Enum class inside an Enum class (but why???) I'd just inherit from Enum: class Colour(Enum): class PrimaryColour(Enum): RED = 1 GREEN = 2 BLUE = 3 OCTARINE = 8 class SecondaryColour(Enum): PUCE = 101 MAUVE = 102 BEIGE = 103 TEAL = 104 > The only example I have seen so far of nested classes in an Enum is when > folks want to make an Enum of Enums, and the nested Enum should not > itself be an enum member. Since the counter-example already works I > haven't seen any requests for it. ;) > > So I'm asking the community: What real-world examples can you offer for > either behavior? Cases where nested classes should be enum members, and > cases where nested classes should not be members. Is this a trick question? :-) -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Should nested classes in an Enum be Enum members?
[Note: there is a similar thread on Python-Ideas, if you would like to respond there.] Consider the following Enum definition: class Color(Enum): RED = 1 GREEN = 2 BLUE = 3 @property def lower(self): return self.name.lower() def spam(self): return "I like %s eggs and spam!" % self.lower class SomeClass: pass Which of the above Color attributes are enums, and which aren't? . . . Answer: - RED, GREEN, and BLUE are members - lower and spam() are not - SomeClass /is/ a member (but not its instances) Question: Should `SomeClass` be an enum member? When would it be useful to have an embedded class in an Enum be an enum member? The only example I have seen so far of nested classes in an Enum is when folks want to make an Enum of Enums, and the nested Enum should not itself be an enum member. Since the counter-example already works I haven't seen any requests for it. ;) So I'm asking the community: What real-world examples can you offer for either behavior? Cases where nested classes should be enum members, and cases where nested classes should not be members. Thanks! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
