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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
