<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> It was mentioned in the other threads, but the requirement is either:<br>
>><br>
>> 1. That the dictionary returned from <enum metaclass>.__prepare__ provide<br>
>> a way to obtain the enum instance names once it's been populated (e.g. once<br>
>> it's been passed as the classdict to __new__). The reference implementation<br>
>> provides a _enum_names list attribute. The enum names need to be available<br>
>> to a metaclass subclass before calling the base metaclass __new__.<br>
>><br>
>> OR<br>
>><br>
>> 2. A way for subclasses of Enum to modify the value before it's assigned<br>
>> to the actual enum - see the PEP 435 reference implementation - discussion<br>
>> thread where I modified the reference implementation to give enum instances<br>
>> 2-phase construction, passing the value to Enum.__init__. This way is more<br>
>> limited, as you need to use an appropriate mix-in type which puts certain<br>
>> constraints on the behaviour of the enum instances (e.g. they *have* to be<br>
>> int instances for auto-numbering). The implementation is also more complex,<br>
>> and as noted in that thread, __init__ might not be appropriate for an Enum.<br>
><br>
><br>
> So your preferred solution is (1), which requires exposing the metaclass and<br>
> an attribute publicly? I have to ask - to what end? What is the goal of<br>
> this? To have an AutoNumberedEnum which is guaranteed to be compatible with<br>
> stdlib's Enum?<br>
><br>
> IMHO this goal is not important enough, and I'm not aware of other stdlib<br>
> modules that go to such lengths exposing implementation details publicly<br>
> (but I'd be happy to be educated on this!)<br>
><br>
> Assuming ref435 goes as-is into stdlib in 3.4, can't you just assume its<br>
> implementation? And then change yours if it changes? Python's stdlib doesn't<br>
> change that often, but if we do want to change the implementation at some<br>
> point, this documented piece of internals is surely going to be in the way.<br>
> Why should the future malleability of a stdlib module be sacrificed for the<br>
> sake of this extension?<br>
<br>
</div></div>Hm. Either you should argue much more strongly against Tim's solution,<br>
or you should expose the implementation detail he needs. Recommending<br>
that he should just use an internal detail of the implementation and<br>
hope it never changes sounds like encouraging a bad habit. It also<br>
seems you're contradicting yourself by saying that the code is<br>
unlikely to change and at the same time wanting to reserve the right<br>
to change it.<br></blockquote><div><br></div><div>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?<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also note that the future malleability of a stdlib module is affected<br>
even by 3rd party use that goes beyond the documented API -- it all<br>
depends on a pragmatic weighing of how important a proposed change is<br>
against how likely it is to break existing use, and there are plenty<br>
of examples in the past where we have resisted changing an<br>
implementation detail because it would break too much code.<br></blockquote><div><br></div><div>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.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you really don't want to guarantee this part of the implementation,<br>
you should recommend that Tim just copy all of ref435. TBH I don't see<br>
what deriving AutoNumberEnum from the stdlib Enum class buy him except<br>
that he has to maintain less code. I don't expect there to be a lot of<br>
opportunities anywhere for writing isinstance(x, Enum).<br></blockquote></div><br></div><div class="gmail_extra">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 ;-)<br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">Eli<br><br></div><div class="gmail_extra"><br></div></div>