[Python-Dev] constant/enum type in stdlib

[Michael Foord]

On 23/11/2010 16:27, Barry Warsaw wrote:
> On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
>
>> Right. As it happens I just submitted a patch to Barry Warsaw's enum package
>> (nice), flufl.enum [1], to allow namedtuple style creation of named
>> constants:
> Thanks for the plug (and the nice patch).
>
> FWIW, the documentation for the package is here:
>
> http://packages.python.org/flufl.enum/
>
> I made some explicit decisions about the API and semantics of this package, to
> fit my own use cases and sensibilities.  I guess you wouldn't expect anything
> else<wink>, but I'm willing to acknowledge that others would make different
> decisions, and certainly the number of existing enum implementations out there
> proves that there are lots of interesting ways to go about it.
>
> That said, there are several things I like about my package:
>
> * 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.

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.


> * 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.

All the best,

Michael

> * Enum items are singletons and are intended to be compared by identity.  They
>    can be compared by equality but are not ordered.
>
> * Enum items have an unambiguous symbolic repr and a nice human readable str.
>
> * Given an enum item, you can get to its enum class, and given the class you
>    can get to the set of items.
>
> * Enums can be subclassed (though all items in the subclass must have unique
>    values).
>
> In any case it may be that enums are too tied to specific use cases to find a
> good common ground for the stdlib.  I've been using my module for years and if
> there's interest I would of course be happy to donate it for use in the
> stdlib.  Like the original sets implementation, it makes perfect sense to
> provide them in a separate module rather than as a built-in type.
>
> -Barry
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


-- 

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101123/218b968e/attachment-0001.html>