cherry pick a change to Enum
Greetings, all! Larry asked me to bring this to PyDev, so here it is. The issues involved are: http://bugs.python.org/issue20534 -> already in RC1 http://bugs.python.org/issue20653 -> hoping to get cherry-picked Background ========== When I put Enum together, my knowledge of pickle and its protocols was dreadfully weak. As a result, I didn't make the best choice in implementing it [1]. Just before RC1 was cut, Serhiy discovered a problem with pickling Enums at protocol four, and with his help I fixed that (this is the part that is already in RC1). This fix consisted primarily of adding a __reduce_ex__ to the Enum class, and also checking for all the pickle protocols in a mixed-in type [2], but I left __getnewargs__ in. Not only that, and worse, I wasn't checking to see if the new subclass had its own __getnewargs__ or __reduce_ex__ before I invalidated the class for pickling [3]. This means that even though a subclass could have its own __reduce_ex__ to make pickling/unpickling possible, it will be ignored. Problem ======= All the previous changes to disallow something have been for strategic reasons (the usual ones being either consistency, or "it doesn't make sense for an enum member/class to behave that way"), but this is effectively disallowing a user to specify how their enums should be pickled, and I am unaware of any reason why this should be. Discussion ========== Is there a valid reason to not allow a user to modify how their enums are pickled? If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but after 3.4.0 is cut we then have to deal with backwards compatibility issues. Thanks for your time and thoughts. -- ~Ethan~ [1] I chose __getnewargs__, with the result that originally Enum didn't support pickle protocols 0 or 1, and when 4 was added later it had trouble with some types of Enum subclasses (tuples, to be exact). [2] Those protocol methods being __reduce__, __reduce_ex__, __getnewargs__, and __getnewargs_ex__. [3] This logic error has been there from the beginning, it did not sneak in in the last patch before RC1.
On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman
Discussion ==========
Is there a valid reason to not allow a user to modify how their enums are pickled?
If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but after 3.4.0 is cut we then have to deal with backwards compatibility issues.
I think this should be cherry-picked. (but see my comment on the issue) Regards Antoine.
On 21 February 2014 20:29, Antoine Pitrou
On Fri, 21 Feb 2014 00:36:09 -0800 Ethan Furman
wrote: Discussion ==========
Is there a valid reason to not allow a user to modify how their enums are pickled?
If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but after 3.4.0 is cut we then have to deal with backwards compatibility issues.
I think this should be cherry-picked. (but see my comment on the issue)
That course of action makes sense to me, too. While we ideally want to catch design bugs during beta, the fact is that we sometime won't notice them until the release candidate phase, and it makes sense to fix them before the final release. However, it also makes sense to discuss the corner cases here before deciding how to proceed, and if we uncover any more after rc2, such a change would probably be a trigger for a 3rd release candidate (although that would ultimately be Larry's call as release manager). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 21, 2014, at 12:36 AM, Ethan Furman wrote:
If not, should we put the change in RC2 / Final? The main reason I'm pushing for this is that Enum is still new, but after 3.4.0 is cut we then have to deal with backwards compatibility issues.
I concur this should be cherry picked. Let's not hobble this API for all eternity <wink> if it can be fixed before the release. Thanks for working so hard to make enums great in Python 3.4. -Barry
participants (4)
-
Antoine Pitrou
-
Barry Warsaw
-
Ethan Furman
-
Nick Coghlan