<div dir="ltr">On Mon, Apr 24, 2017 at 11:56 AM, Aldcroft, Thomas <<a href="mailto:aldcroft@head.cfa.harvard.edu" target="_blank">aldcroft@head.cfa.harvard.edu</a><wbr>> wrote:<br>><br>> On Mon, Apr 24, 2017 at 2:47 PM, Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>> wrote:<br>>><br>>> On Mon, Apr 24, 2017 at 10:51 AM, Aldcroft, Thomas <<a href="mailto:aldcroft@head.cfa.harvard.edu" target="_blank">aldcroft@head.cfa.harvard.edu</a><wbr>> wrote:<br>>> ><br>>> > On Mon, Apr 24, 2017 at 1:04 PM, Chris Barker <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br>>><br>>> >> - round-tripping of binary data (at least with Python's encoding/decoding) -- ANY string of bytes can be decodes as latin-1 and re-encoded to get the same bytes back. You may get garbage, but you won't get an EncodingError.<br>>> ><br>>> > +1.  The key point is that there is a HUGE amount of legacy science data in the form of FITS (astronomy-specific binary file format that has been the primary file format for 20+ years) and HDF5 which uses a character data type to store data which can be bytes 0-255.  Getting an decoding/encoding error when trying to deal with these datasets is a non-starter from my perspective.<br>>><br>>> That says to me that these are properly represented by `bytes` objects, not `unicode/str` objects encoding to and decoding from a hardcoded latin-1 encoding.<br>><br>> If you could go back 30 years and get every scientist in the world to do the right thing, then sure.  But we are living in a messy world right now with messy legacy datasets that have character type data that are *mostly* ASCII, but not infrequently contain non-ASCII characters.<br><br>I am not unfamiliar with this problem. I still work with files that have fields that are supposed to be in EBCDIC but actually contain text in ASCII, UTF-8 (if I'm lucky) or any of a variety of East European 8-bit encodings. In that experience, I have found that just treating the data as latin-1 unconditionally is not a pragmatic solution. It's really easy to implement, and you do get a program that runs without raising an exception (at the I/O boundary at least), but you don't often get a program that really runs correctly or treats the data properly.<br><br>Can you walk us through the problems that you are having with working with these columns as arrays of `bytes`?<br><br>> So I would beg to actually move forward with a pragmatic solution that addresses very real and consequential problems that we face instead of waiting/praying for a perfect solution.<br><br>Well, I outlined a solution: work with `bytes` arrays with utilities to convert to/from the Unicode-aware string dtypes (or `object`).<div><br></div><div>A UTF-8-specific dtype and maybe a string-specialized `object` dtype address the very real and consequential problems that I face (namely and respectively, working with HDF5 and in-memory manipulation of string datasets).<br></div><div><br></div><div><div>I'm happy to consider a latin-1-specific dtype as a second, workaround-for-specific-<wbr>applications-only-you-have-<wbr>been-warned-you're-gonna-get-<wbr>mojibake option. It should not be *the* Unicode string dtype (i.e. named np.realstring or np.unicode as in the original proposal).</div><div><br></div></div><div>--<br>Robert Kern</div></div>