<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 7:11 PM, Chris Barker - NOAA Federal <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</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"><span class="gmail-">> On Apr 25, 2017, at 12:38 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
<br>
> Eh... First, on Windows and MacOS, filenames are natively Unicode.<br>
<br>
</span>Yeah, though once they are stored I. A text file -- who the heck<br>
knows? That may be simply unsolvable.<br>
<span class="gmail-">> s. And then from in Python, if you want to actually work with those filenames you need to either have a bytestring type or else a Unicode type that uses surrogateescape to represent the non-ascii characters.<br>
<br>
<br>
</span><span class="gmail-">> IMO if you have filenames that are arbitrary bytestrings and you need to represent this properly, you should just use bytestrings -- really, they're perfectly friendly :-).<br>
<br>
</span>I thought the Python file (and Path) APIs all required (Unicode)<br>
strings? That was the whole complaint!<br>
<br>
And no, bytestrings are not perfectly friendly in py3.<br>
<br>
This got really complicated and sidetracked, but All I'm suggesting is<br>
that if we have a 1byte per char string type, with a fixed encoding,<br>
that that encoding be Latin-1, rather than ASCII.<br>
<br>
That's it, really.<br></blockquote><div><br></div><div>Fully agreed.</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">
<br>
Having a settable encoding would work fine, too.<br></blockquote><div><br></div><div>Yup.</div><div><br></div><div>At a simple level, I just want the things that currently work just fine in Py2 to start working in Py3. That includes being able to read / manipulate / compute and write back to legacy binary FITS and HDF5 files that include ASCII-ish text data (not strictly ASCII).  Memory mapping such files should be supportable.  Swapping type from bytes to a 1-byte char str should be possible without altering data in memory.</div><div><br></div><div>BTW, I am saying "I want", but this functionality would definitely be welcome in astropy.  I wrote a unicode sandwich workaround for the astropy Table class (<a href="https://github.com/astropy/astropy/pull/5700">https://github.com/astropy/astropy/pull/5700</a>) which should be in the next release.  It would be way better to have this at a level lower in numpy.<br></div><div><br></div><div>- Tom</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">
<br>
-CHB<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<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>
</div></div></blockquote></div><br></div></div>