<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 24, 2017 at 4:06 PM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Can you walk us through the problems that you are having with working with these columns as arrays of `bytes`?</div></blockquote><div><br></div><div>This is very simple and obvious but I will state for the record.  Reading an HDF5 file with character data currently gives arrays of `bytes` [1].  In Py3 this cannot be compared to a string literal, and comparing to (or assigning from) explicit byte strings everywhere in the code quickly spins out of control.  This generally forces one to convert the data to `U` type and incur the 4x memory bloat.</div><div><br></div><div><div>In [22]: dat = np.array(['yes', 'no'], dtype='S3')</div><div><br></div><div>In [23]: dat == 'yes'  # FAIL (but works just fine in Py2)</div><div>Out[23]: False</div><div><br></div><div>In [24]: dat == b'yes'  # Right answer but not practical</div><div>Out[24]: array([ True, False], dtype=bool)</div></div><div><br></div><div>- Tom</div><div><br></div><div>[1]: Using h5py or pytables.  Same with FITS, although astropy.io.fits does some tricks under the hood to auto-convert to `U` type as needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><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></span>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-applic<wbr>ations-only-you-have-been-<wbr>warned-you're-gonna-get-mojiba<wbr>ke 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>
<br>______________________________<wbr>_________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
<br></blockquote></div><br></div></div>