<div class="gmail_quote">On 17 June 2011 07:39, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div id=":11z">I guess we could make it a configurable option, but I&#39;m not even sure<br>
it&#39;s worth the added complexity, so I&#39;m mildly -1 on going down that<br>
road, unless I can be convinced that the implementation isn&#39;t that<br>
complicated and that there&#39;s really a *major* usability win for<br>
certain users for whom the default is just too annoying to bear.</div></blockquote><div><br>The complexity in terms of code is fairly minimal - a boolean config variable, and an if/else inside run_cell should cover it. The main downside would be the added load on testing and maintenance - if the variable became widely used, any bug report relating to unicode would leave us asking which way the user had it set.<br>

<br>I&#39;ll leave it to Jörgen to put the case for usability.<br><br>In fact, I&#39;ve just worked out a way round the issue, although it&#39;s not pretty. If we were to encode each cell, and prepend the &quot;# coding: &lt;enc&gt;&quot; magic comment before parsing it, it seems to work. However, the line numbers within the cell are then out by 1 (i.e. if you see a traceback). As far as I can tell, there&#39;s no way to store this state between compile/parse calls - codeop.Compile doesn&#39;t remember it. I don&#39;t much like the idea of doing this, though.<br>

<br>Thanks,<br>Thomas<br></div></div>