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@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.
_______________________________________________
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
