> From: Guido van Rossum [mailto:guido@python.org] > > No way. If any kind of version number is encoded in a pickle, it > should be the pickle protocol version. Unlike marshalled data, > pickles are guraranteed future-proof, and also backwards compatible, > unless the pickled data itself depends on Python features (for > example, an instance of a list subclass pickled in Python 2.2 can't be > unpickled in older Python versions). Each subsequent pickle protocol > is a superset of the previous protocol. > > There are use cases that have many pickles containing very small > amounts of data, where adding a version header to each pickle would > amount to a serious increase of data size. Maybe we can afford adding > one byte to indicate the new version number (so that unpicklers that > don't speak the new protocol will die cleanly), but I think that's > about it. Sorry - that's more or less what I meant ... that there would be a mapping between the version and a magic number (the pickle protocol version). This could also be achieved by passing in the `sys.version_info` - it would be mapped to the appropriate number. Multiple versions may well use the same pickle protocol, but should the protocol numbers be made visible to the user? The "version number" (pickle protocol) would be an indicator to earlier versions that they don't know how do deal with this protocol ... essentially "you must be this version or higher to use this". Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4