On 2008-10-22 01:34, Martin v. Löwis wrote:
>> What makes you think that the problem cannot be fixed without changing
>> the existing pickle format 0?
> 
> Applications might rely on what was implemented rather than what was
> specified. If they had implemented their own pickle readers, such
> readers might break if the pickle format is changed. In principle, even
> the old pickle readers of Python 2.0..2.6 might break if the format
> changes in 2.7 - we would have to go back and check that they don't
> break (although I do believe that they would work fine).
> 
> So I personally don't see a problem with fixing this, but it appears
> MAL does (for whatever reasons - I can't quite buy the performance
> argument). OTOH, I don't feel that this issue deserves as much of
> my time to actually implement anythings.

I've had a look at the implementations used in both pickle.py
and cPickle.c: both apply some extra escaping to the encoded
version of raw-unicode-escape in order to handle newlines
correctly, so I guess adding a few more escapes won't hurt.

So +0 on adding the extra escapes for range(128,256) code
points.

Still, IMHO, all of this is not worth the effort, since protocol
versions 1 and 2 are more efficient and there are better ways to
deal with the problem of sending binary data in some ASCII format,
e.g. using base64.