<div dir="ltr">On Wed, Apr 26, 2017 at 5:02 PM, Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br><br>> But a bunch of folks have brought up that while we're messing around with string encoding, let's solve another problem:<br>><br>> * Exchanging unicode text at the binary level with other systems that generally don't use UCS-4.<br>><br>> For THAT -- utf-8 is critical.<br>><br>> But if I understand Julian's proposal -- he wants to create a parameterized text dtype that you can set the encoding on, and then numpy will use the encoding (and python's machinery) to encode / decode when passing to/from python strings.<br>><br>> It seems this would support all our desires:<br>><br>> I'd get a latin-1 encoded type for compact representation of mostly-ascii data.<br>><br>> Thomas would get latin-1 for binary interchange with mostly-ascii data<br>><br>> The HDF-5 folks would get utf-8 for binary interchange (If we can workout the null-padding issue)<br>><br>> Even folks that had weird JAVA or Windows-generated UTF-16 data files could do the binary interchange thing....<br>><br>> I'm now lost as to what the hang-up is.<br><br>The proposal is for only latin-1 and UTF-32 to be supported at first, and the eventual support of UTF-8 will be constrained by specification of the width in terms of characters rather than bytes, which conflicts with the use cases of UTF-8 that have been brought forth.<br><br>  <a href="https://mail.python.org/pipermail/numpy-discussion/2017-April/076668.html">https://mail.python.org/pipermail/numpy-discussion/2017-April/076668.html</a><div><br>--<br>Robert Kern</div></div>