<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 5, 2013 at 10:46 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 5 May 2013 07:09:14 -0700<br>
<div class="im">Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> > On Sat, 4 May 2013 15:04:49 -0700<br>
> > Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> > > Hello pydev,<br>
> > ><br>
> > > PEP 435 is ready for final review. A lot of the feedback from the last<br>
> > few<br>
> > > weeks of discussions has been incorporated.<br>
> ><br>
> > I still would like to see Nick's class-based API preferred over the<br>
> > functional API:<br>
> ><br>
> >    class Season(Enum, members='spring summer autumn'):<br>
> >       pass<br>
> ><br>
> > The PEP doesn't even mention it, even though you got significant<br>
> > pushback on the proposed _getframe() hack for pickling (including<br>
> > mentions that IronPython and Cython may not support it),<br>
><br>
> Plenty of points were raised against having this members= API.<br>
<br>
</div>The main point seems to be "I don't like it". If you consider this a<br>
strong argument against the concrete issues with the functional API,<br>
then good for you.<br>
<div class="im"><br>
> Guido publicly asked to decide in favor of the<br>
> functional API, and we added an explicit warning about pickling (which was<br>
> lifted from the docs of pickle itself).<br>
<br>
</div>This is not true. The pickling restrictions which have been raised are<br>
specifically caused by the functional syntax, something which your<br>
warning omits.<br>
<div class="im"><br>
> If you feel this has to be<br>
> discussed further, please open a new thread. I don't want another 100<br>
> bikeshedding emails to go into this one.<br>
<br>
</div>This is not bikeshedding since it addresses concrete functional issues.<br>
(but apparently you would very much like to sweep those issues under<br>
the carpet in the name of "bikeshedding")<br>
</blockquote><div><br></div><div>I'm sorry that you're taking this issue so personally, Antoine.<br><br></div><div>As for pickling enums created with the functional API, I don't think we now provide less than the pickle module dictates in the general sense. The pickle docs say:<br>

<br>The following types can be <span class="">pickle</span>d:<br>  [...]<br><ul class=""><li>classes that are defined at the top level of a module</li><li>instances of such classes whose <tt class=""><span class="">__dict__</span></tt> or the result of calling
<tt class=""><span class="">__getstate__()</span></tt> is picklable  (see section <a class="" href="http://docs.python.org/dev/library/pickle.html?highlight=pickle#pickle-inst"><em>Pickling Class Instances</em></a> for
details).</li></ul>I'll open a separate thread about how this can be implemented and documented in the best way possible, but I really don't see it as an unsolvable issue.<br><br>Eli<br><br></div><div> </div></div>

<br></div></div>