On Tue, Nov 23, 2010 at 11:47 AM, Barry Warsaw <ba...@python.org> wrote: > On Nov 23, 2010, at 05:02 PM, Michael Foord wrote: > >>> * Enums are not subclassed from ints or strs. They are a distinct data type >>> that can be converted to and from ints and strs. EIBTI. >> >>But if we are to use it *in* the standard library (as opposed to merely >>adding a module *to* the standard library) there are backwards compatibility >>concerns. Where modules are already using integers for constants then >>integers still need to work. > > Is int(enum_value) enough, or must the enum value actually *be* an int?
I vote for *be*, following bool's example. >>One easy way to achieve this is to subclass integer. If we don't do that >>(assuming we decide that putting a solution in the standard library is >>appropriate) then we'll have to evaluate what we mean by backwards >>compatible. If the modules that use the constants aren't to change then >>comparing equal to the underlying value is the minimum (so that the original >>value can still be used in place of the new named constant). Not sure if >>you'd be happy to make that change in flufl.enum. > > I'm not sure either. In flufl.enum enum_class(i) also works as expected. > >>> * The typical way to create them is through a simple, but explicit class >>> definition. I personally like being explicit about the item values, and >>> the assignments are required to make the metaclass work properly, but >>> Michael's convenience patch is totally appropriate for cases where you >>> don't care, or you want a one-liner. >> >>If make_enum was to take a set of values to use (as Antoine suggested) I >>don't see what's un-explicit about it. > > When I saw your patch I immediately thought that I could add a default > argument that was something like `int_iter`, i.e. an iterator of integers for > the values in the string. I suspect YAGNI, which is why I didn't just add it, > but I'm not totally opposed to it. > > -Barry > > _______________________________________________ > 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/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
