Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
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 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). -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
On 15.03.15 07:52, Ethan Furman wrote: So how do we fix it? There are a couple different options: - modify IntEnum pickle methods to return the name only - modify IntEnum pickle methods to pickle just like the int they represent The first option has the advantage that in 3.4 and above, you'll get back the IntEnum version. The second option has the advantage that the actual pickle contents are the same [1] as in previous versions. So, the final question: Do the contents of a pickle file at a certain protocol have to be the some between versions, or is it enough if unpickling them returns the correct object? With the second option you lost the type even for 3.5+. This is a step back. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
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~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
On Sat, 14 Mar 2015 22:52:17 -0700 Ethan Furman wrote: > I'm not sure exactly how to phrase this inquiry, so please bear with me. > > What exactly does backwards compatibility mean as far as pickle goes? We > have the various protocols, we have the > contents of pickle files created at those protocols, and we have different > versions of Python. > > Should a pickle file created in Python 3.4 with protocol 3 and the contents > of socket.AF_INET be unpicklable with a > Python 3.3 system? Because currently it cannot be as socket.AF_INET became > an IntEnum in 3.4. > > I'm thinking the answer is yes, it should be. I agree with you that this should not break. > So, the final question: Do the contents of a pickle file at a certain > protocol have to be the some between versions, or > is it enough if unpickling them returns the correct object? It's certainly enough if unpickling returns the correct object. Exact serialization is an implementation detail. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
Huzzah! Thanks for working on this one folks, it should make the zipfile execution support much easier for current and future Python users to discover :) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
