On 8/31/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(Adding back py3k list assuming you just forgot it)</blockquote><div><br>Yes, thanks. Gmail's UI really optimizes the "Reply To" operation of "Reply To All." <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Plus, it sounds like you're proposing that the encodings of the underlying<br>> data would leak through to the application. As I understood Fredrick's<br>> model, the intention was to treat the encoding as an implementation detail.
<br>> If it works well, this could be an important differentiator for Python<br>> (versus Java) as Unicode already is (versus Ruby).<br><br>*Only* for UTF-16, which I consider a necessary evil since we can't<br>rewrite the Java and .NET standards.
</blockquote><div><br></div>I see what you're getting at.<br><br>I'd say that decoding UTF-16 data in CPython and PyPy should (by default) create true Unicode characters. Jython and IronPython could create surrogates and characters when necessary. When you run the program in CPython you'll get better behaviour than in Jython/IronPython. Maybe there could be a way to make CPython run like Jython and IronPython if you wanted 100% absolute compatibility between the environments. I think that we agree that it would be unfortunate if CPython copied Java and .NET to its own detriment. It's also not inconceivable that Java and .NET might evolve a 4-byte mode in the long term.
<br><br> Paul Prescod<br><br></div>