[Python-Dev] Best practices for Enum (original) (raw)
Raymond Hettinger raymond.hettinger at gmail.com
Mon May 13 01:49:44 CEST 2013
- Previous message: [Python-Dev] 2.7.5 baking
- Next message: [Python-Dev] Best practices for Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
After the long design effort for the enum module, I'm sure there will be a forthcoming effort to apply them pervasively throughout the standard library.
I would like to ask for a little restraint and for there to be individual cost/benefit evaluations for each case.
On the plus-side, the new integer-enums have a better repr than plain integers.
For internal constants such as those in idlelib and regex, the user won't see any benefit at all. But there will be a cost in terms of code churn, risk of introducing errors in stable code, modestly slowing-down the code, making it more difficult to apply bug fixes across multiple versions of Python, and increased code verbosity (i.e. changing "if direction=LEFT: ..." to "if direction is Direction.LEFT: ...")
For external constants, some thought needs to be given to:
- is the current API working just fine (i.e. decimal's ROUND_DOWN)
- will enums break doctests or any existing user code
- will it complicate users converting from Python 2
- do users now have to learn an additional concept
- does it complicate the module in any way
I'm hoping that enums get used only in cases where they clearly improve the public API (i.e. cases such as sockets that have a large number of integer constants) rather than having a frenzy of every constant, everywhere getting turned into an enum.
I would like to see enums used as tool for managing complexity, rather than becoming a cause of added complexity by being used for every problem, the tall and small, even where it is not needed at all.
my-two-cents-ly yours,
Raymond
- Previous message: [Python-Dev] 2.7.5 baking
- Next message: [Python-Dev] Best practices for Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]