RetroSearch Browse

Tue Nov 19 21:25:34 CET 2013 · https://mail.python.org/pipermail/python-dev/2013-November/130375.html

Am 19.11.13 20:59, schrieb Antoine Pitrou:
> That's integrated to the built-in buffering. It's not really an
> additional constraint: the frame sizes simply dictate how buffering
> happens in practice. The main point of framing is to *simplify* the
> buffering logic (of course, the old buffering logic is still there for
> protocols <= 3, unfortunately).

I wonder why this needs to be part of the pickle protocol at all,
if it really is "below" the opcodes. Anybody desiring framing could
just implement a framing version of the io.BufferedReader, which
could be used on top of a socket connection (say) to allow fetching
larger blocks from the network stack. This would then be transparent
to the pickle implementation; the framing reader would, of course,
provide the peek() operation to allow the unpickler to continue to use
buffering.

Such a framing BufferedReader might even be included in the standard
library.

Regards,
Martin

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

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

[Python-Dev] Accepting PEP 3154 for 3.4?