<div dir="ltr">Oscar,<div><br></div><div style>Cool stuff, thanks!</div><div style><br></div><div style>I'm wondering though what the use-case really is. The P3 text  model (actually the py2 one, too), is quite clear that you want users to think of, and work with, text as text -- and not care how things are encoding in the underlying implementation. You only want the user to think about encodings on I/O -- transferring stuff between systems where you can't avoid it. And you might choose different encodings based on different needs.</div>

<div style><br></div><div style>So why have a different, the-user-needs-to-think-about-encodings numpy  dtype? We already have 'U' for full-on unicode support for text. There is a good argument for a more compact internal representation for text compatible with one-byte-per-char encoding, thus the suggestion for such a dtype. But I don't see the need for quite this. Maybe I'm not being a creative enough thinker.</div>

<div style><br></div><div style>Also, we may want numpy to interact at a low level with other libs that might have binary encoded text (HDF, etc) -- in which case we need a bytes dtype that can store that data, and perhaps encoding and decoding ufuncs.</div>

<div style><br></div><div style>If we want a more efficient and compact unicode implementation  then the py3 one is a good  place to start -it's pretty slick! Though maybe harder to due in numpy as text in numpy probably wouldn't be immutable.</div>

<div style><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To make a slightly more concrete proposal, I've implemented a pure<br>
Python ndarray subclass that I believe can consistently handle<br>
text/bytes in Python 3.</blockquote><div><br></div><div style>this scares me right there -- is it text or bytes??? We really don't want something that is both.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The idea is that the array has an encoding. It stores strings as<br>
bytes. The bytes are encoded/decoded on insertion/access. Methods<br>
accessing the binary content of the array will see the encoded bytes.<br>
Methods accessing the elements of the array will see unicode strings.<br>
<br>
I believe it would not be as hard to implement as the proposals for<br>
variable length string arrays.</blockquote><div><br></div><div style>except that with some encodings, the number of bytes required is a function of what the content of teh text is -- so it either has to be variable length, or a fixed number of bytes, which is not a fixed number of characters  which require both careful truncation (a pain), and surprising results for users  "why can't I fit 10 characters is a length-10 text object? And I can if they are different characters?)</div>

<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The one caveat is that it will strip<br>
null characters from the end of any string. </blockquote><div><br></div><div style>which is fatal, but you do want a new dtype after all, which presumably wouldn't do that.</div><div style><br></div><div style>-Chris</div>

<div style> </div><div style><br></div></div>-- <br><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>

Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>
</div></div>