[Python-Dev] Best practices for Enum (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Mon May 13 05:15:55 CEST 2013
- Previous message: [Python-Dev] Best practices for Enum
- Next message: [Python-Dev] Best practices for Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ethan Furman writes:
I will certainly ask for advice on which modules to spend my time on. I know enums are not a cure-all, but they are great for debugging and interactive work.
Especially in new code where they are used throughout. Not so in the existing stdlib, I expect.
The concrete limitation on that theory that I envision with retrofitting the stdlib is that cooperative modules (those that call into and are called from the module being converted to use enums) are going to be expecting values, not enums. So you need to convert return values and arguments, and not only do you not get the benefit of enum reprs in the cooperating modules, but you introduce additional complexity in the converted module. Nor can you say "OK, it's more than I expected but I'll do the whole stdlib," because you don't know who is calling into or supplying callbacks to the stdlib modules.
I expect you would recognize these cases quickly, but I imagine Raymond is feeling a more generic unease, and I can't say I blame him.
In many cases you could convert code to use IntEnum instead of Enum, preserving the old semantics, and probably not needing to convert return values, but again I expect the benefits of Enum-ness would attenuate quickly as cooperating code converts them to int internally.
- Previous message: [Python-Dev] Best practices for Enum
- Next message: [Python-Dev] Best practices for Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]