Message187834
| Author |
pitrou |
| Recipients |
alexandre.vassalotti, asvetlov, neologix, pitrou, rhettinger, serhiy.storchaka |
| Date |
2013年04月26日.06:47:15 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1366958832.2582.1.camel@fsol> |
| In-reply-to |
<1366958622.95.0.939603903102.issue17810@psf.upfronthosting.co.za> |
| Content |
> I don't see what this would bring over explicit compression:
> - depending on the use case, you may want to use different compression algorithms, e.g. for disk you may want higher compression ratio like bzip2/lzma, but for wire you'd prefer something fast like snappy
> - supporting multiple compression algorithms and levels would complicate the API
> - this would probably complicate the code, since you'd have to support optional compression, and have a way to indicate which format is used
> - that's really mixing two entirely different concepts (serialization vs compression)
I agree with Charles-François.
A feature that may be actually nice to have in the pickle protocol would
be some framing, to help with streaming unpickling (right now unpickling
a stream can read almost one byte at a time, IIRC).
However, that would also make the protocol and the pickler significantly
more complex. |
|