<br><br><div class="gmail_quote">On Fri, Aug 3, 2012 at 7:03 PM, Travis Oliphant <span dir="ltr">&lt;<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
Ondrej has been working hard with feedback from many others on improving Unicode support in NumPy (especially for Python 3.3).   Looking at what Python has done in Python 3.3 (PEP 393) and chatting on the Python issue tracker with the author of that PEP has made me wonder if we aren&#39;t &quot;doing the wrong thing&quot; in NumPy quite often.<br>

<br>
Basically, NumPy only supports UTF-32 in it&#39;s Unicode representation.   All bytes in NumPy arrays should be either UTF-32LE or UTF-32BE.    This is all pretty easy to understand as long as you stick with NumPy arrays only.<br>

<br>
The difficulty starts when you start to interact with the unicode array scalar (which is the same data-structure exactly as a Python unicode object with a different type-name --- numpy.unicode_).    However, I overlooked the &quot;encoding&quot; argument to the standard &quot;unicode&quot; constructor which might have simplified what we are doing.    If I understand things correctly, now, all we need to do is to &quot;decode&quot; the UTF-32LE or UTF-32BE raw bytes in the array (depending on the dtype) into a unicode object.<br>

<br>
This is easily accomplished with  numpy.unicode_(&lt;bytes object&gt;, &#39;utf_32_be&#39;  or &#39;utf_32_le&#39;).    There is also an &quot;encoding&quot; equivalent to go from the Python unicode object to the bytes representation in the NumPy array.   I think this is what we should be doing in most of the places and it should considerably simplify the Unicode code in NumPy --- eliminating possibly the ucsnarrow.c file.<br>

<br>
Am I missing something?<br>
<br></blockquote><div><br>I can&#39;t comment on the rest, but I&#39;d be happy to see the end of the ucsnarrow.c file. It needs more work to be properly generalized and if there is a way to avoid that, so much the better.<br>
<br>Chuck <br></div><br></div>