[Python-Dev] Accepting PEP 3154 for 3.4? (original) (raw)
Tim Peters tim.peters at gmail.com
Tue Nov 19 23:06:22 CET 2013
- Previous message: [Python-Dev] Accepting PEP 3154 for 3.4?
- Next message: [Python-Dev] Accepting PEP 3154 for 3.4?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Antoine]
Ahah, ok, I see where you're going. But how many other implementations of unpickling are there?
[Tim]
That's something you should have researched when writing the PEP ;-) How many implementations of Python aren't CPython? That's probably the answer. I'm not an expert on that, but there's more than one.
[Antoine]
But "how many of them use something else than Lib/pickle.py" is the actual question.
I don't know - and neither do you ;-)
I do know that I'd like, e.g., a version of pickletools.dis() in CPython that did show the framing bits, for debugging. That's a bare-bones "unpickler". I don't know how many other "partial unpicklers" exist in the wild either. But their lives would also be much easier if the framing stuff were explicit. "Mandatory optimization" should be an oxymoron ;-)
... The problem with "let's make the unpickler more lenient in a later version" is that then you have protocol 4 pickles that won't work with all protocol 4-accepting versions of the pickle module.
Yup. s/4/5/ would need to be part of a delayed optimization.
- Previous message: [Python-Dev] Accepting PEP 3154 for 3.4?
- Next message: [Python-Dev] Accepting PEP 3154 for 3.4?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]