Bringing back on list. :) On 03/15/2015 12:18 AM, Glenn Linderman wrote:

On 3/14/2015 11:58 PM, Ethan Furman wrote:

...

On 03/14/2015 11:46 PM, Glenn Linderman wrote:

...

In general, it would seem to me that each version of Python could add object types that are foreign to prior versions, and so as long as version N can unpickle anything produced by versions <=N, all would be well.

The question to me is because we are not so much adding something brand-new (socket.AF_INET has been there for ages), as changing the type of something already existing -- I'm just not sure if we need "end-result" compatibility (achieved by the first option) or if we need "bug for bug" compatibility (achieved by the second option).

Yes, the fact that it is not brand-new does add a mind-twist to the compatibility expectations. But while it is not brand-new, it is changed.

Exactly. IntEnum was advertised as being a "drop-in replacement" with the only change being better reprs and strs; so being unable to un-pickle in prior versions invalidates that claim. Part 2 of my question (Part 1 of which is "which method do we use to fix the IntEnum being used in the stdlib") is: do we just change the IntEnum subclasses (such as socket.AddressFamily) to have the fixed behavior, or do we change IntEnum itself? Having thought about it for a few minutes, we cannot make that change in IntEnum itself as it only works if the names are exported to the global namespace -- so this fix will work for the stdlib (since we export the names), but won't work otherwise. Unless someone steps forward and says that the actual pickle contents must be the same, I'm going to go with pickling the name: this is both unpicklable in prior versions, and doesn't lose the type in present versions. Just to be clear, there are no issue unpickling in the same version, only in prior versions. -- ~Ethan~