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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com