Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: 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. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2980> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
