A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2013-November/130335.html below:

[Python-Dev] Accepting PEP 3154 for 3.4?

[Python-Dev] Accepting PEP 3154 for 3.4? [Python-Dev] Accepting PEP 3154 for 3.4?Antoine Pitrou solipsis at pitrou.net
Mon Nov 18 23:08:52 CET 2013
On Mon, 18 Nov 2013 16:02:31 -0600
Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
> >> Clearly the framing is the weakest point of the PEP (== elicits the most
> >> bikeshedding). I am also unsure about the value of framing when pickles are
> >> written to strings.
> 
> [Antoine]
> > It hasn't much value in that case,
> 
> It has _no_ value in that case, yes?  It doesn't appear to have _much_
> value in the case of a seekable stream, either - the implementation
> has always been free to read ahead then.  The real value appears to be
> in cases of non-seekable streams.
> 
> 
> > but the cost is also small (8 bytes every 64KB, roughly).
> 
> >> That's small if your pickle is large, but for small pickles it can add up.
> 
> Which is annoying.  It was already annoying when the PROTO opcode was
> introduced, and the size of small pickles increased by 2 bytes.  That
> added up too :-(

Are very small pickles that size-sensitive? I have the impression that
if 8 bytes vs. e.g. 15 bytes makes a difference for your application,
you'd be better off with a hand-made format.

Regards

Antoine.
More information about the Python-Dev mailing list

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