[Python-Dev] PEP 435: initial values must be specified? Yes

[Guido van Rossum]

On Sun, May 5, 2013 at 3:55 PM, Eli Bendersky <eliben at gmail.com> wrote:
>
>
>
> On Sun, May 5, 2013 at 3:34 PM, Tim Delaney <timothy.c.delaney at gmail.com>
> wrote:
>>
>> On 6 May 2013 08:00, Guido van Rossum <guido at python.org> wrote:
>>>
>>> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney <timothy.c.delaney at gmail.com>
>>> wrote:
>>> > So long as I can get one of the requirements documented to implement an
>>> > auto-number syntax I'll be happy enough with stdlib enums I think.
>>>
>>> Specifically what do you want the PEP to promise?
>>
>>
>> It was mentioned in the other threads, but the requirement is either:
>>
>> 1. That the dictionary returned from <enum metaclass>.__prepare__ provide
>> a way to obtain the enum instance names once it's been populated (e.g. once
>> it's been passed as the classdict to __new__). The reference implementation
>> provides a _enum_names list attribute. The enum names need to be available
>> to a metaclass subclass before calling the base metaclass __new__.
>>
>> OR
>>
>> 2. A way for subclasses of Enum to modify the value before it's assigned
>> to the actual enum - see the PEP 435 reference implementation - discussion
>> thread where I modified the reference implementation to give enum instances
>> 2-phase construction, passing the value to Enum.__init__. This way is more
>> limited, as you need to use an appropriate mix-in type which puts certain
>> constraints on the behaviour of the enum instances (e.g. they *have* to be
>> int instances for auto-numbering). The implementation is also more complex,
>> and as noted in that thread, __init__ might not be appropriate for an Enum.
>
>
> So your preferred solution is (1), which requires exposing the metaclass and
> an attribute publicly? I have to ask - to what end? What is the goal of
> this? To have an AutoNumberedEnum which is guaranteed to be compatible with
> stdlib's Enum?
>
> IMHO this goal is not important enough, and I'm not aware of other stdlib
> modules that go to such lengths exposing implementation details publicly
> (but I'd be happy to be educated on this!)
>
> Assuming ref435 goes as-is into stdlib in 3.4, can't you just assume its
> implementation? And then change yours if it changes? Python's stdlib doesn't
> change that often, but if we do want to change the implementation at some
> point, this documented piece of internals is surely going to be in the way.
> Why should the future malleability of a stdlib module be sacrificed for the
> sake of this extension?

Hm. Either you should argue much more strongly against Tim's solution,
or you should expose the implementation detail he needs. Recommending
that he should just use an internal detail of the implementation and
hope it never changes sounds like encouraging a bad habit. It also
seems you're contradicting yourself by saying that the code is
unlikely to change and at the same time wanting to reserve the right
to change it.

Also note that the future malleability of a stdlib module is affected
even by 3rd party use that goes beyond the documented API -- it all
depends on a pragmatic weighing of how important a proposed change is
against how likely it is to break existing use, and there are plenty
of examples in the past where we have resisted changing an
implementation detail because it would break too much code.

If you really don't want to guarantee this part of the implementation,
you should recommend that Tim just copy all of ref435. TBH I don't see
what deriving AutoNumberEnum from the stdlib Enum class buy him except
that he has to maintain less code. I don't expect there to be a lot of
opportunities anywhere for writing isinstance(x, Enum).

-- 
--Guido van Rossum (python.org/~guido)