On Tue, 3 Apr 2018 at 01:19 Serhiy Storchaka <storchaka@gmail.com> wrote:
03.04.18 01:57, Lukasz Langa пише:
>> On Apr 2, 2018, at 2:13 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
>> On Mon, 2 Apr 2018 13:48:46 -0700
>> Lukasz Langa <lukasz@langa.pl> wrote:
>>> Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped as part of Python 3.4 back in 2011. Yet it's still not the default.
>> Because we want pickles produced with the default to be readable by
>> earlier Python 3 versions.
>> (the same reason protocol 0 stayed the default throughout the Python 2
>> lifetime)
>
> Alright, so that means we can easily do this for Python 3.8, right? I mean, following Christian's logic, Python 3.3 is already dead, with its final release done in February 2016 and support dropped in September 2017 per PEP 398.
>
> I think we need to get past thinking about "Python 2" vs. "Python 3". This frame of mind creates space for another mythical release of Python that will break all the compatibilities, something we promised not to do. A moving backward compatibility window that includes the last release still under security fixes seems like a good new framework for this.
>
> What do you think?

The only possible drawback of protocol 4 is that very short pickles can
be longer than with protocol 3 due to additional 9 bytes for the FRAME
header and less compact pickling of globals.

This may be partially compensated by implementing additional
optimizations and/or passing short pickles through pickletools.optimize().

I think if you're that worried about specifics to that detail then you should be specifying the protocol level manually anyway. I view this like something in the peepholer: a freebie perf bump for those that aren't too worried about such things. :)