[Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum

[Ethan Furman]

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~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150315/d5448bcb/attachment.sig>