<br><br><div><span class="gmail_quote">On 11/1/07, <b class="gmail_sendername">Facundo Batista</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2007/11/1, Guido van Rossum <<a href="mailto:email@example.com">firstname.lastname@example.org</a>>:<br><br>> I could leave this all up to the 3.0 application, which would have to<br>> "fix up" any bytes in the pickle it receives explicitly if it wants
<br>> to. Alternatively, I could add an encoding option to the pickle<br>> loading APIs (and for full flexibility an errors option as well) so<br>> that at least simple text-based applications might have a chance of
<br>> reading the data that they themselves wrote before they were ported to<br>> 3.0 with minimal changes (only the unpickling calls would have to be<br>> modified).<br><br>I think that to make possible to the unpickling appl to specify which
<br>encoding to use is the best option here, so to avoid:<br><br>- Need to change the appl that created the pickle (that can be not accesible).<br><br>- Have to make the work by hand of dealing with that "fix up" everywhere.
<br><br>- Requests from developers to add a "magic guess" to discover<br>automatically which encoding use.<br><br>Regards,<br><br>--<br>. Facundo</blockquote><div><br>Brainstorming here... how about an optional callable argument when unpickling to let the developers write their own "magic guess" function? This callable should take a single parameter and its return value would be used as the unpickled string.
<br><br>Or is that too much work and not enough context in the callable to be useful? People could just as easily write code to recurse through the unpickled output converting the appropriate bytes objects as needed.<br><br>