[Python-Dev] Best practices for Enum

Ethan Furman ethan at stoneleaf.us
Mon May 13 06:50:55 CEST 2013


On 05/12/2013 08:15 PM, Stephen J. Turnbull wrote:
> 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.

Perhaps not to somebody who is already well versed in it.  It would be very helpful to me. ;)


> 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.

Well, somebody else might, but I know how much (little?) time I have.  It'll be great to have new modules use Enums; 
retrofitted modules should use Psuedonums (okay, I made that word up -- it's supposed to be an Enum but with some other 
type mixed in so it's no longer a pure Enum, more like a psuedo enum).  As I was saying, if tkinter was up for 
conversion it would just be to StrEnum, and that would mostly consist of adding the enumeration at the top, exporting it 
to global, then browsing for locations where the string value was used and removing the quotes.  Of course, having said 
that I'm sure somebody will chime in with "yes, but..."


> 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.

Hmmm... yeah, that would suck.

Well, I'm sure I can help in others ways if this doesn't pan out.  Maybe some other new module that Raymond objects to.  ;)

--
~Ethan~


More information about the Python-Dev mailing list