<div dir="ltr">Now my proposal for the other use cases:<div><br></div><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2) There be some way to store mostly ascii-compatible strings in a single byte-per-character array -- so not to be wasting space for "typical european-language-oriented data". Note: this should ALSO be compatible with Python's character-oriented string model. i.e. a Python String with length N will fit into a dtype of size N.<br></div><div class="gmail_quote"><br></div><span class=""><div class="gmail_quote">arr = np.array(("this", "that",), dtype=np.single_byte_string)<br><br>(name TBD)<br><br>and arr[1] would return a python string.<br><br></div></span><div class="gmail_quote">attempting to put in a not-compatible with the encoding String  would raise an EncodingError.<br><br>This is also a use-case primarily for "casual" users -- but ones concerned with the size of the data storage and know that are using european text.<br></div></div></div></blockquote><div><br></div><div>more detail elsewhere -- but either ascii with surrageescape or latin-1 always are good options here. I prefer latin-1 (I really see no downside), but others disagree...</div><div><br></div><div>But then we get to:</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">3) dtypes that support storage in particular encodings:</div></div></div></blockquote><div><br></div><div>We need utf-8. We may need others. We may need a 1-byte per char compact encoding that isn't close enough to ascii or latin-1 to be useful (say, shift-jis), And I don't think we are going to come to a consensus on what "single" encoding to use for 1-byte-per-char.</div><div><br></div><div>So really -- going back to Julian's earlier proposal:</div><div><br></div><div>dytpe with an encoding specified</div><div>"size" in bytes</div><div><br></div><div>once defined, numpy would encode/decode to/from python strings "correctly"</div><div><br></div><div>we might need "null-terminated utf-8" as a special case.</div><div><br></div><div>That would support all the other use cases.</div><div><br></div><div>Even the one-byte per char encoding. I"d like to see a clean alias to a latin-1 encoding, but not a big deal.</div><div><br></div><div>That leaves a couple decisions: </div><div><br></div><div> - error out or truncate if the passed-in string is too long?</div><div><br></div><div> - error out or suragateescape if there are invalid bytes in the data?</div><div><br></div><div> - error out or something else if there are characters that can't be encoded in the specified encoding.</div><div><br></div><div>And we still need a proper bytes type:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">4) a fixed length bytes dtype -- pretty much what 'S' is now under python three -- settable from a bytes or bytearray object (or other memoryview?), and returns a bytes object.<br><br></div><div class="gmail_quote">You could use astype() to convert between bytes and a specified encoding with no change in binary representation. This could be used to store any binary data, including encoded text or anything else. this should map directly to the Python bytes model -- thus NOT null-terminted.</div><div class="gmail_quote"><br></div><div class="gmail_quote">This is a little different than 'S' behaviour on py3 -- it appears that with 'S', a if ALL the trailing bytes are null, then it is truncated, but if there is a null byte in the middle, then it is preserved. I suspect that this is a legacy from Py2's use of "strings" as both text and binary data. But in py3, a "bytes" type should be about bytes, and not text, and thus null-values bytes are simply another value a byte can hold.<br></div></div></div></blockquote><div><br></div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><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></div></div>