Message91980
| Author |
RonnyPfannschmidt |
| Recipients |
RonnyPfannschmidt, loewis |
| Date |
2009年08月26日.18:18:02 |
| SpamBayes Score |
5.8901624e-05 |
| Marked as misclassified |
No |
| Message-id |
<1251310680.24112.9.camel@localhost> |
| In-reply-to |
<4A95786B.4050906@v.loewis.de> |
| Content |
Since it breaks for anything non-ascii, its not that helpfull after all
and since python2 strings are encoding-unaware there is no way to fix
it.
It might be preferable to supply unpicklers that are cappable of
coercing if the user really wants wants coercing.
yup
>
> > 3. python 3 string map to python 2 unicode
>
> That's also the case, AFAICT.
yup
>
> > 4. python 3 bytestring maps to python 2 string
>
> Hmm. This may be indeed a mistake. Until r61467, bytes were saved
> with the (BIN)STRING code; not sure why this was changed.
Python 3 is indeed evil there.
b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01\x85q\x02Rq\x03.'
I'm convinced that a 1:1 mapping of python2 string from/to python3
bytestrings is the least surprising behaviour and will keep surprising
errors away when needing to communicate between different python
versions.
It just has bitten me, and i suspect will will get others, too.
Unpickle that completely fails in the face of encodings is not desirable
at all. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年08月26日 18:18:05 | RonnyPfannschmidt | set | recipients:
+ RonnyPfannschmidt, loewis |
| 2009年08月26日 18:18:03 | RonnyPfannschmidt | link | issue6784 messages |
| 2009年08月26日 18:18:02 | RonnyPfannschmidt | create |
|