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/130326.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 17:10:15 CET 2013
On Mon, 18 Nov 2013 07:48:27 -0800
Guido van Rossum <guido at python.org> wrote:
> On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka <storchaka at gmail.com>wrote:
> 
> > 18.11.13 07:53, Tim Peters написав(ла):
> >
> >  - Some easy sanity checking due to the tiny redundancy (if the byte
> >> immediately following the current frame is not a FRAME opcode, the
> >> pickle is corrupt; and also corrupt if a FRAME opcode is encountered
> >> _inside_ the current frame).
> >>
> >
> > For efficient unpickling a FRAME opcode followed by 8-byte count should be
> > *last* thing in a frame (unless it is a last frame).
> >
> 
> I don't understand that.
> 
> 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.

It hasn't much value in that case, but the cost is also small (8 bytes
every 64KB, roughly).

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