This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan.furman
Recipients alexandre.vassalotti, barry, eli.bendersky, ethan.furman, gvanrossum, larry, pitrou, python-dev, serhiy.storchaka
Date 2014-02-21.05:18:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1392959940.63.0.491193907019.issue20653@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for your comments, Eli, I'll work on getting better comments in the code.

The qualname comment is partially related to the pickling changes as it's necessary for protocol 4 (I forgot to put that comment in on the previous pickling change that addressed that issue).

I reopened because a new (or another) patch with better comments is called for; I tagged it 3.4 because I thought default was still pointing to the 3.4 series.

To answer here your other questions (which I'll also put in comments in the code):

1.  if custom pickling is desired __reduce_ex__ needs to be defined
2.  if (1) is not done, then normal pickle behavior takes place:
    i.  check if this is a mixed or pure Enum
    ii. if mixed, check that mixed-in type (aka member_type) has a pickle
        protocol in place, and if it doesn't, have the resulting enum class
        have __reduce_ex__ be the _break_on_call_reduce method.  We do this
        because even though the class and member will pickle, the member
        will fail to unpickle.
3.  as I said in an earlier message, but didn't make clear:  __reduce_ex__ is
    the preferred method.  This means that if a class has both __reduce__ and
    __reduce_ex__, __reduce__ will be ignored (at least by pickle -- I haven't
    researched copy, which I think also uses __reduce__ and/or __reduce_ex__).
    And of course, if an ancestor class has __reduce_ex__, and a subclass has
    __reduce__, the subclass really has both.  No, __reduce__ is not checked for.
History
Date User Action Args
2014-02-21 05:19:00ethan.furmansetrecipients: + ethan.furman, gvanrossum, barry, pitrou, larry, alexandre.vassalotti, eli.bendersky, python-dev, serhiy.storchaka
2014-02-21 05:19:00ethan.furmansetmessageid: <1392959940.63.0.491193907019.issue20653@psf.upfronthosting.co.za>
2014-02-21 05:19:00ethan.furmanlinkissue20653 messages
2014-02-21 05:18:59ethan.furmancreate