On Thu, Jul 28, 2011 at 10:12 AM, Barry Warsaw <barry@python.org> wrote:
On Jul 27, 2011, at 07:21 PM, Guido van Rossum wrote:
It's just possible that there's no way to define enums that neither introduced a new (class) scope nor requires a lot of redundant typing.
Ezio had a very nice suggestion, which I've implemented in my experimental branch, e.g.:
>>> foo = sys.modules['foo'] >>> Colors.inject(foo)
.inject() takes anything that implements the setattr() protocol. So that you could then do:
>>> import foo >>> foo.red Colors.red
Nice, but it still hides the definitions from static analyzers. It seems I am almost unique in my insistence that Python's dynamic features be used very sparingly. :-)
In my experimental branch I've also made EnumValues subclasses of ints. This breaks one test in my Mailman 3 test suite, since I was using a custom encoder for json.dumps() which knew how to encode EnumValues. However, the json module doesn't allow you to override the encoding of basic types, so whereas before my extended encoder's .default() method got called for all the EnumValues being encoded in a REST response, they are now encoded *incorrectly* as their integer values by default. I'd need to figure out a workaround for that, but it does show that EnumValue-as-int is a backward incompatible change.
Sure. Almost any change is backward incompatible...
A few other things I've done in my experimental branch:
- Added an optional argument `iterable` to make_enum() so that you can use the convenience function to auto-assign integer values other than sequentially incrementing from 1. E.g.
>>> def enumiter(): ... start = 1 ... while True: ... yield start ... start <<= 1 >>> make_enum('Flags', 'a b c d e f g', enumiter()) <Flags {a: 1, b: 2, c: 4, d: 8, e: 16, f: 32, g: 64}>
- Renamed attributes .enumclass -> .enum and .enumname -> .name (hey, if you're going to be backward incompatible...)
If you want to play with it:
$ bzr branch lp:~barry/flufl.enum/asint
or take a look at:
http://bazaar.launchpad.net/~barry/flufl.enum/asint/files
The new using.txt file is at:
Let me know what you think, while I figure out a workaround for the incompatible change.
Cheers, -Barry
-- --Guido van Rossum (python.org/~guido)