<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 5, 2013 at 3:34 PM, Tim Delaney <span dir="ltr"><<a href="mailto:timothy.c.delaney@gmail.com" target="_blank">timothy.c.delaney@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On 6 May 2013 08:00, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br>

</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sun, May 5, 2013 at 2:55 PM, Tim Delaney <<a href="mailto:timothy.c.delaney@gmail.com" target="_blank">timothy.c.delaney@gmail.com</a>> wrote:<br>
> So long as I can get one of the requirements documented to implement an<br>
> auto-number syntax I'll be happy enough with stdlib enums I think.<br>
<br>
</div>Specifically what do you want the PEP to promise?<br></blockquote><div><br></div></div><div>It was mentioned in the other threads, but the requirement is either:</div><div><br></div><div>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__.</div>


<div><br></div><div>OR</div><div><br></div><div>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.</div>

<span class="HOEnZb"><font color="#888888"></font></span></div></div></div></blockquote></div><br></div><div class="gmail_extra">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? <br>

<br>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!)<br><br></div><div class="gmail_extra">

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

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