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

[Eli Bendersky]

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

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
sense?


> 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 ;-)

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130505/7e1bb22a/attachment-0001.html>