Jrgen&#39;s found that there&#39;s still a unicode problem in trunk, which I don&#39;t think can be completely resolved, but we&#39;d like to get some more opinions on it.<br><br>The issue is that, while we can parse Python code as either unicode or bytes, there&#39;s no way to indicate what encoding is used in either case. So:<br>

1. If we parse as unicode, non-ascii characters which occur inside byte literals are always interpreted as bytes by encoding with utf-8. This is what we now do in trunk.<br>2. If we parse as bytes, bytes occurring inside unicode literals are always interpreted as characters by decoding with cp1252.<br>

<br>The necessary parameter is not going to be included in Python, because it&#39;s not a problem in Python 3: <a href="http://bugs.python.org/issue5911">http://bugs.python.org/issue5911</a><br><br>The practical upshot is platform dependent:<br>

1 will always work correctly when the user enters u&quot;&quot; (unicode literals), and will coincidentally work with byte literals where the terminal uses utf-8 (as I believe most Linux and Mac terminals do).<br>2 will always work as you&#39;d expect when the user enters &quot;&quot; (bytes literals), and will coincidentally work with unicode literals where the terminal uses cp1252 (Windows computers in English speaking countries and parts of Europe).<br>

<br>I&#39;m fairly confident that 1 is the better approach - it&#39;s critical that you can enter those characters as part of a unicode string, but less so that you can enter them in a byte string. Also, most of our users are on Linux or Mac, so it should &#39;just work&#39; for more people.<br>

<br>The question is whether we want to try to include a workaround for other cases. Where stdin_encoding is cp1252, we could encode each cell as cp1252 before parsing it. That would then behave as expected in the two commonest situations (UTF-8 unix terminals and cp1252 windows terminals). On the downside, it&#39;s an horrendously ugly hack, and I don&#39;t know what it would do on platforms other than CPython. Jrgen also suggested making it an option, although I wonder how many people will ever find it.<br>

<br>My own inclination is simply to say that non-ascii characters will be interpreted correctly in unicode literals, but their behaviour in byte literals is undefined, and you should use the &#39;\xe9&#39; notation to write bytes above 127. Note that Python 3 actually enforces this rule: b&quot;&quot; is a SyntaxError. But I&#39;d like to collect some more thoughts, or see if we can come up with a way to avoid the problem (short of writing our own parser).<br>

<br>Thanks for reading this - it took me a while to properly understand the problem, so I hope I&#39;ve explained it clearly.<br><br>Thomas<br>