[Python-Dev] PEP 435: initial values must be specified? Yes
eliben at gmail.com
Mon May 6 01:24:10 CEST 2013
> >> It was mentioned in the other threads, but the requirement is either:
> >> 1. That the dictionary returned from <enum metaclass>.__prepare__
> >> a way to obtain the enum instance names once it's been populated (e.g.
> >> it's been passed as the classdict to __new__). The reference
> >> provides a _enum_names list attribute. The enum names need to be
> >> 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 -
> >> thread where I modified the reference implementation to give enum
> >> 2-phase construction, passing the value to Enum.__init__. This way is
> >> limited, as you need to use an appropriate mix-in type which puts
> >> constraints on the behaviour of the enum instances (e.g. they *have* to
> >> int instances for auto-numbering). The implementation is also more
> >> and as noted in that thread, __init__ might not be appropriate for an
> > So your preferred solution is (1), which requires exposing the metaclass
> > 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
> > 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
> > 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
> > Why should the future malleability of a stdlib module be sacrificed for
> > 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.
OK, then I'll say without contradictions that I don't expect the
implementation of Enum to be stable at this point. We don't even *have* an
implementation yet. All we have is some (pretty good!) code Ethan wrote and
I only partially reviewed. The final implementation may be completely
different, and then again we may want to change it in light of new input. I
wouldn't want to constrain ourselves at this point. Perhaps when 3.4 is
branched will be a point in time in which this can be re-visited. Makes
> 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.
Agreed, but if we document these details, we're forever bound, pragmatic
weighing notwithstanding. Also, in this particular case if auto-numbered
enums in the class API are deemed super-useful we may end up incorporating
a syntax for them anyway, which will render the external module obsolete.
> 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).
That's what I was trying to say, I guess. Even if the chance of changing
the implementation of Enum is pretty low (after 3.4 I mean, before that
it's pretty damn high), I don't think that restricting ourselves here is
justified by Tim's maintaining less code in his external module. With all
due respect, of course ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev