On Tue, 19 Nov 2013 21:25:34 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
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.
Well, unless you propose a patch before Saturday, I will happily ignore your proposal. Regards Antoine.