On 30 January 2013 01:27, Barry Warsaw <barry@python.org> wrote:
On Jan 28, 2013, at 11:50 PM, Joao S. O. Bueno wrote:
And it was not dismissed at all - to the contrary the last e-mail in the thread is a message from the BDLF for it to **be** ! The discussion happened in a bad moment as Python was mostly freature froozen for 3.2 - and it did not show up again for Python 3.3;
I still offer up my own enum implementation, which I've used and has been available for years on PyPI, and hasn't had a new release in months because it hasn't needed one. :) It should be compatible with Pythons from 2.6 to 3.3.
http://pypi.python.org/pypi/flufl.enum
The one hang up about it the last time this came up was that my enum items are not ints and Guido though they should be. I actually tried at one point to make that so, but had some troublesome test failures that I didn't have time or motivation to fix, mostly because I don't particularly like those semantics. I don't remember the details.
However, if someone *else* wanted to submit a branch/patch to have enum items inherit from ints, and that was all it took to have these adopted into the stdlib, I would be happy to take a look.
Being an int subclass (and possibly optionally a strs subclass) is a requirement if any adopted Enum is to be used *within* the standard library in places where integers are currently used as "poor man's enums". I also don't *think* flufl.enum supports flag enums (ones that can be OR'd together), right? Michael
Cheers, -Barry
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html