[Python-ideas] constant/enum type in stdlib

[Tim Delaney]

On 12 February 2013 00:28, Eli Bendersky <eliben at gmail.com> wrote:

> On Sun, Feb 10, 2013 at 2:43 PM, Tim Delaney <timothy.c.delaney at gmail.com>wrote:
>
>> On 4 February 2013 11:17, Tim Delaney <timothy.c.delaney at gmail.com>wrote:
>>
>>> On 4 February 2013 10:53, João Bernardo <jbvsmo at gmail.com> wrote:
>>>
>>>> Particularly It would be nice to have custom attributes and methods
>>>> besides the value and the name.
>>>>
>>>
>> I've also made it so that you can override the metaclass to return a
>> subclass of EnumValue.
>>
>> Can you elaborate on the utility of this feature? What realistic use
> cases do you see for it? I think that at this point it's important to weigh
> all benefits of features vs. implementation complexity, and there's
> absolutely no need to support every feature every other enum implementation
> has. I want to stress again that the most important characteristic of your
> implementation is the clean syntax which means that enums are so easy to
> define they don't really need special Python syntax and a library feature
> can do. However, there's a big leap from this to defining custom
> metaclasses for enums.
>

The custom metaclass is purely a mechanism to make it easy to use a custom
class for the enum value. It wold be possible to manually assign a custom
enum type to each enum, but then you wold lose the ability to just define
the names. By using a custom metaclass, you can have it automatically
assign the enum value type that you want.

My next email specifies a simplified syntax for specifying the custom
metaclass (you don't need to create one at all).

Supporting this functionality was actually very simple. However, I am
wondering though how useful this is without being able to specify
additional parameters for the enums. I've often used enums with quite
complex behaviour (e.g. in java) - the enum part is purely to have a unique
value assigned to each instance of the class and not repeating myself for
no good reason. I couldn't quite do the same with this as it currently is -
whilst I can have whatever behaviour I want, there's nothing to key it off
except the name and value which probably isn't enough. I've been trying to
think of a syntax which would work to pass additional parameters and I
can't think of anything cleaner than having a specialised class to pass the
additional parameters - but I need to somehow be able to specify the
optional integer value of the enum. Maybe have the first parameter be None?

class EnumParams():
    def __init__(self, value=None, *p, **kw):
        self.value = value
        ....

    def _resolve_proxies(self):
        # names would have been affected by EnumValues.__getattr__ - need
to resolve them from _EnumProxy to the actual values

...

class MyEnumValue(EnumValue):
    def __new__(cls, key, value, *p):
        e = super().__new__(cls, key, value)
        e.p = p

    def dump(self):
        print(self.p)

class MyEnum(Enum, metaclass=Enum.subtype(MyEnumValue)):
    A = EnumParams(None, 'extra', 'params')
    B = EnumParams(3, 'more', 'params')

Thoughts? Is the extra complexity worth it? The thing is, this doesn't take
away from the ability to specify the very simple clean enums - but it would
give the enums pretty much the full capabilities of java enums.

I'd like to have all these features available so that any PEP could
reference them and discuss the pros and cons (including how well they work
in practice).

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130212/19d42e31/attachment.html>