[Python-Dev] enum discussion: can someone please summarize open issues? (original) (raw)

Steven D'Aprano steve at pearwood.info
Mon Apr 29 07:36:23 CEST 2013

On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:

Two examples:

- the first few integers (up to 256 now, I think) are pre-created by the interpreter; when you do int('7') you are not getting a brand-new, never before used, integer 7 object, you're getting a cached integer 7 object. - all booleans (yup, both of them ;) are pre-created; when you ask for a True or a False, you are not getting a brand new one. Since is is discouraged, both of those cases could go the other way (always creating a brand new object) and properly written programs would continue to run just fine -- slower, but fine. Enums are the same: they could return brand new instances every time, and programs using == to compare will keep on working. That they don't is an implementation detail.

That's not how I understand it. I expected that the correct way to use enums is with identity checks:

if arg is Season.SUMMER: handle_summer()

At least, that's how I'm used to dealing with sentinels or pseudo-enums created with object(), and I just expected it to carry over to actual enums. Should I reset my thinking and use == with flufl.enums?

-- Steven

More information about the Python-Dev mailing list